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; shortreserved; }; + 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