OpenEuphoria

Re: Contest Update

• Posted by CoJaBo <cojabo at suscom.net> Nov 08, 2004
• 544 views

Andy Serpa wrote:
> 
> 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</font></i>
> > 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 is one reason I always open files in binary mode.

> 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."
If anyone finds a program that can run on a burnt computer,
Id like to have a copy to use on my old laptop... 

>