syphir@xxxxxxxxxxxxxxxx(C.Y.M) 19.06.05 20:57
Once upon a time "C.Y.M " shaped the electrons to say...
>Starting with vdr-1.3.26, the recording date in VDR uses DD-MM-YY,
>instead of just DD-MM. When I compare the latest enAIO patch for
>vdr-1.3.27 with the previous patch for vdr-1.3.26, it looks like the
>array has gone back to the original size of 6. Is this correct?
>+--- vdr-1.3.26/recording.c 2005-06-05 07:11:45.000000000 -0700
>++++ vdr-1.3.27/recording.c 2005-06-19 08:06:39.000000000 -0700
> @@ -52,6 +52,7 @@
> #endif
> #define INFOFILESUFFIX "/info.vdr"
>@@ -911,7 +911,7 @@
> + else {
> + struct tIndex { int offset; uchar type; uchar number; short
>reserved; }; + tIndex *index;
>-+ char RecLength[21], RecDate[6], RecTime[6], RecDelimiter[2];
>++ char RecLength[21], RecDate[9], RecTime[6], RecDelimiter[2];
> + if (Setup.ShowRecLength) {
> + char *filename = NULL;
> + int last = -1;
That's reason to avoid such "magic numbers"...
I don't know if gcc supports that, but
i am used to define such arrays
char RecLength[sizRECLEN],
RecDate[sizeof("DD-MM-YY")],
RecTime[sizeof("000000")],
RecDelimiter[sizeof("\00")]; (or what ever explains why that
should be "2")
As "sizeof" delivers a constant while at compile time there
should be no need to use "magic numbers".
Ideally it should read
#define SIZRECDATE (sizeof("DD-MM-YY"))
...
Too it may ease the move to unicode that some day will come...
But it seems to very uncommon practise in linux code to
define magic numerbers using "#defines".
It would save a lot of time as the code is easier to maintain
and faster to understand.
Rainer
