[vdr] A difference b/n vdr-1.3.26-enAIO-2.3.diff and vdr-1.3.27-enAIO-2.3.diff

[Rainer Zocholl]

syphir at syphir.sytes.net(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