Re: Contest Update
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 08, 2004
- 545 views
Andy Serpa wrote: > Derek Parnell wrote: >> >> I'll give a hint that some people may have tripped up on. >> >> A file opened as "text" will appear to prematurely end if it contains >> the End-Of-File marker for text files. > > I suspected that might be the case. But penalizing the programmer for > treating a file that is supposed to be text as text seems wrong. It > the input file was not to be treated as text, then the rules should say > that tokens contain the *bytes*: > > {65,66,67, etc.} > > instead of: > > "ABC ... etc." > > Making an assumption that one should continue after an EOF marker could > be wrong if this was a "real-world" application. Maybe in a certain context. However, AFAIK most modern programs use the size of a file in order to detect its end, rather than the occurrence of the ASCII 26 character. In another context, continuing after an ASCII 26 character might be absolutely reasonable. Users of one of my programs explicitly have asked me to change the program, so that it *does* continue after an ASCII 26 character. This is because text files sometimes get corrupted, so that an EOF marker gets somewhere inside it, where it was never intended to be. I changed the program, so that it reads the text files in binary mode, and replaces every ASCII 26 character with the string "<EOF>". It's very robust now. > Sticking to this esoterica would seem to be making the contest about > "who can best interpret logical loopholes in the rules" rather than > best program a well-defined task. Derek's rules stated clearly: "The file should only contain bytes in the range #00 - #7F". This includes 26. <snip> Regards, Juergen