Author: Dave Gomboc
Date: 01:33:27 10/25/02
Go up one level in this thread
On October 24, 2002 at 15:47:37, Dann Corbit wrote:
>On October 23, 2002 at 21:40:23, Dave Gomboc wrote:
>
>>On October 23, 2002 at 15:25:04, Colin Frayn wrote:
>>
>>>Then I suddenly realised. Carlos had been sending strings to the engine of the
>>>form;
>>>3r4/5b2/1k1r1p2/Np5p/4P1p1/2R1KPP1/2P4P/R7 w
>>>
>>>(i.e. missing off the last two dashes.) The full string should be
>>>3r4/5b2/1k1r1p2/Np5p/4P1p1/2R1KPP1/2P4P/R7 w - -
>>>
>>>but of course the shortened version should still be valid.
>>
>>Why do you say that? All those fields are required. The EPD parsing code I
>>ahve written throws an exception on your first example. Sounds like that would
>>have saved you a lot of grief!
>
>If castling is impossible, it's not hard to figure out what the flags are.
>Leaving them out is a common mistake.
>
>Similarly, Winboard will accept all sorts of goo as PGN. It just silently eats
>the ugly crud and turns it into a clean version.
Leaving the castling and en-passant flags out is a common mistake only because
broken tools accept them instead of rejecting them. I strongly believe that
it's simply better to gratuitously reject non-conforming input. Colin will
hardly be the last person to slave for days to hunt down a bug that was caused
by slack input parsing. Input parsing is a *notorious* place for bugs, probably
because most people want to get it over with and get on with the "real"
programming.
Recent example: take a slighly old version of crafty, and set the time to
0.137258 seconds ("st 0.137258") -- and check out the time limit that is
actually set! Bob fixed this input parsing bug in about 15 seconds -- once I
had spent a chunk of time trying to figure out what was wrong with _my_ code
that was communicating with crafty. The basic problem was that crafty assumed
the time sent to it would have resolution of at most in the hundredths of
seconds. But unfortunately, nothing in the code actually verified that that was
the case. Had it done so, and signalled an error, I would have understood the
problem immediately, and either changed my code to suit, or sent him a code
patch in 15 seconds myself. And perhaps while writing that checking code he
would have realized that it was a pain in the neck to make that check, and have
came up with the idea of just reading in a floating-point number in the first
place, in which case the bug would have never been there at all.
If one wants to implement automatic cleaning-up of EPD strings, PGN files, or
what have you, I think it should be done in distinct code expressly written for
the purpose. When you do that, you'll be focusing more carefully on the
possible things that might be wrong. But at a bare minimum, a compromise would
be to present a user-visible warning when the mandatory fields are absent. This
isn't as good as outright rejection, though, because the individual might have
just added the missing fields after he saw that his software didn't work but
that a warning had been emitted. In that case, the developer might not have
been notified, or might have not bothered to look at it carefully because the
person who noted the problem had already worked around it; the code itself would
still contain the bug.
Dave
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.