Re: Contest Update

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu