C.Y.M wrote:

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;
  
  

I believe the previous patch using "RecDate[9]" is the correct size. Else, the day is cut off.

C.

syphir@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