Fulvio wrote: ↑Sat Dec 19, 2020 8:14 pm
That's mate and it is also considered valid by Stockfish.
If it were not a mate, it would still be illegal.
If you want to exclude positions that cannot be reached in a normal game that would be trickier.
Yes, which is why I'm asking if there's any working code that checks this. If there's none, and no clear way of writing one, I'm not sure if “it's the GUI's problem” is ever going to create a secure system as a whole.
Are you aware of any position of that type that cause problems with Stockfish?
This very thread had an example of a position that cause problems with Leela. I have no idea what kind of illegal/impossible positions are allowed or not with Stockfish, but as long as the only spec is “reached by a series of legal chess moves from the starting position”, there's no guarantee that what's working today will keep working after the next Stockfish update.
Fulvio wrote: ↑Sat Dec 19, 2020 11:28 am
Good engineering is not about right and wrong, good or evil; it is about building things that works as expected.
Exactly. And regardless of what you say, people do not expect software to crash on invalid input, except in some very specific circumstances.
If the UCI GUI is not buggy and the UCI engine complies with the spec, there will be no crash or freeze (or worse).
Do you think ld should be allowed to crash when confronted with an unknown file format?
It will be difficult to avoid all crashes if something is wrong with the executable.
Even an executable in a supported format may crash if the cpu doesn't support AVX512 and the executable was compiled for AVX512. Running arbitrary executables is a dangerous business and can wipe out all your files.
So, if the executable is valid for another platform but not for the current platform, it would be helpful to inform the user that the format isn't supported, but I wouldn't consider this a hard requirement (unless some spec requires it and you want to comply with that spec).
Do you think ld should be allowed to crash when confronted with an unknown file format?
It will be difficult to avoid all crashes if something is wrong with the executable.
Even an executable in a supported format may crash if the cpu doesn't support AVX512 and the executable was compiled for AVX512. Running arbitrary executables is a dangerous business and can wipe out all your files.
Isn't this conflating ld (the linker) with ld.so (the dynamic loader)? ld doesn't normally run executables it's linking.
Fulvio wrote: ↑Sat Dec 19, 2020 8:14 pm
That's mate and it is also considered valid by Stockfish.
If it were not a mate, it would still be illegal.
If you want to exclude positions that cannot be reached in a normal game that would be trickier.
Yes, which is why I'm asking if there's any working code that checks this. If there's none, and no clear way of writing one, I'm not sure if “it's the GUI's problem” is ever going to create a secure system as a whole.
Are you aware of any position of that type that cause problems with Stockfish?
This very thread had an example of a position that cause problems with Leela. I have no idea what kind of illegal/impossible positions are allowed or not with Stockfish, but as long as the only spec is “reached by a series of legal chess moves from the starting position”, there's no guarantee that what's working today will keep working after the next Stockfish update.
I agree that this is the weakest point of the "leave it to the GUI" approach. I would be surprised if there is any GUI that refuses to send to the engine a position in which two pawns give check.
So if UCI leaves it to the GUI, which it does according to its creator, it should also specify the requirements of a "valid" position (since the FIDE definition of a legal position is way too cumbersome to implement correctly).
Stefan Meyer-Kahlen in response to Tim Mann wrote:>What should the engine do if the GUI sends it an illegal move in a
>position command? What about an illegal position (several kings, etc.)?
This should not happen as the GUI has to take care of it.
>What bestmove should be returned by "go" if there are no legal moves?
If there is no legal move the engine won't get a "go" command.
Stefan Meyer-Kahlen wrote:We wanted to make the engines as simple as posible, so the main work has to be done by the interface. All critital points like no legal moves or illegal moves has to be handled by the GUI.
Tim Mann wrote:>>What should the engine do if the GUI sends it an illegal move in a
>>position command? What about an illegal position (several kings, etc.)?
>
>This should not happen as the GUI has to take care of it.
I see. It's another case where the GUI has to be smart: it must not allow an illegal position or move. This can get a bit tricky, since an engine's idea of a legal position can vary a bit. The user might want to put in a puzzle position that could not be reached in an actual game; in some cases this might violate an assumption inside the engine. For instance, the engine might "know" that there can be no more than 9 white queens on the board, or no more than 16 white pieces, etc. Some engines crash or otherwise object when you exceed such limits because they have fixed-size internal data structures that overflow.
Do you think ld should be allowed to crash when confronted with an unknown file format?
It will be difficult to avoid all crashes if something is wrong with the executable.
Even an executable in a supported format may crash if the cpu doesn't support AVX512 and the executable was compiled for AVX512. Running arbitrary executables is a dangerous business and can wipe out all your files.
Isn't this conflating ld (the linker) with ld.so (the dynamic loader)? ld doesn't normally run executables it's linking.
Yes it is
I would be very suprised if ld the linker cannot be made to crash. Unless someone rewrote it in Java, in which case it will overflow your terminal with stack traces.
Do you think ld should be allowed to crash when confronted with an unknown file format?
It will be difficult to avoid all crashes if something is wrong with the executable.
Even an executable in a supported format may crash if the cpu doesn't support AVX512 and the executable was compiled for AVX512. Running arbitrary executables is a dangerous business and can wipe out all your files.
Isn't this conflating ld (the linker) with ld.so (the dynamic loader)? ld doesn't normally run executables it's linking.
Yes it is
I would be very suprised if ld the linker cannot be made to crash. Unless someone rewrote it in Java, in which case it will overflow your terminal with stack traces.
Tomorrow I will see what happens if I feed it some corrupt .o files. Perhaps it will go down in flames after all (in which case I would be quite disappointed).
Note that is entirely the same as the Stockfish/GUI case. ld is supposed to process valid .o files (produced by a c-compiler or perhaps assembler). So it would be "within specs" if it does just that and crashes on everything else.
I find it hard to believe that the maintainers would accept this philosophy. But as I said I did not actually try.
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.
Do you think ld should be allowed to crash when confronted with an unknown file format?
It will be difficult to avoid all crashes if something is wrong with the executable.
Even an executable in a supported format may crash if the cpu doesn't support AVX512 and the executable was compiled for AVX512. Running arbitrary executables is a dangerous business and can wipe out all your files.
Isn't this conflating ld (the linker) with ld.so (the dynamic loader)? ld doesn't normally run executables it's linking.
Yes it is
I would be very suprised if ld the linker cannot be made to crash. Unless someone rewrote it in Java, in which case it will overflow your terminal with stack traces.
Tomorrow I will see what happens if I feed it some corrupt .o files. Perhaps it will go down in flames after all (in which case I would be quite disappointed).
Note that is entirely the same as the Stockfish/GUI case. ld is supposed to process valid .o files (produced by a c-compiler or perhaps assembler). So it would be "within specs" if it does just that and crashes on everything else.
I find it hard to believe that the maintainers would accept this philosophy. But as I said I did not actually try.
syzygy wrote: ↑Sat Dec 19, 2020 11:39 pm
I would be very suprised if ld the linker cannot be made to crash. Unless someone rewrote it in Java, in which case it will overflow your terminal with stack traces.
syzygy wrote: ↑Sat Dec 19, 2020 11:37 pm
So if UCI leaves it to the GUI, which it does according to its creator, it should also specify the requirements of a "valid" position (since the FIDE definition of a legal position is way too cumbersome to implement correctly).
I wonder what happens if we introduce the following two concessions:
We do not care about the full-move and half-move clocks; they just need to be integers in some defined range.
We assume that pawns were allowed to move backwards (but not to the base rank) and sideways, up to but not including the last move.
It seems to me this reduces the problem from a near-impossible one to merely a difficult one. The former fixes a lot of parity issues and such, mainly related to the openings. The latter makes sure we don't need to go through great contortions to invalidate positions such as “starting position but with the rook on a1 moved to a3” (now possible since the pawn could have moved to a4, the rook moved out and then the pawn back), which are illegal under the strict FIDE definition but irrelevant for almost any kind of engine algorithm.
This still leaves some tricky issues about checks; there's the double-pawn-check as mentioned earlier (and similar situations, such as double-bishop-checks), and also some funny issues about X-ray checks: K1qq3k/8/8/8/8/6b1/8/8 (white to move) is legal but K1qq3k/8/8/8/8/7b/8/8 is not!
