OpenEuphoria

Re: Contest Update

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 07, 2004
• 490 views

Patrick Barnes wrote:
> 
> On Sun, 07 Nov 2004 14:50:20 -0800, Andy Serpa <guest at rapideuphoria.com>
> wrote:
> > Making an assumption that one should continue after an EOF marker could be
> > wrong if this was
> a "real-world" application.  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.</font></i>
> > 
> > Alternatively, simply put in a rule that says, "Input files should be opened
> > in binary mode".
> 
> I believe that this is covered in the programming style criteria:
> "Defensive coding that is tolerant of bad data." That's why files 6-11
> are there - they contain a lot of border cases that may trip up
> programs less tolerant. You're not penalised anywhere near as much for
> making mistakes with these files than you are with the first 5.
> 
> 
I understand bad data, but ignoring an EOF marker in a text file is making an
assumption that I wouldn't neccessarily consider correct.  Some data is so "bad"
that you can't expect the program to know what to do with it (unless that case is
explicitly covered in the rules).  Should I make guesses at what other "bad"
bytes in the file are "supposed to be" and adjust my token counts accordingly?

I just don't think it is reasonable, just as if there was a rule that said,
"Program must continue to perform while computer is set on fire."