TalkChess.com

That should be undefined behaviour, and it has always been. Especially the GCC team is well-known to have taken an ever more aggressive stance towards undefined behaviour. If the code is broken, then each GCC update will increase the odds of actually manifesting the code issues.

My new chess engine has no evaluation function and therefore move generation speed becomes more important. Not having an evaluation function? So it just generates moves, searches through trees, and then doesn't evaluate them? Did you actually benchmark how much time the move generation takes? I don...

I'd not use assembly because porting that needs separate code paths for each CPU architecture. E.g. how would you make an Android version? It's also not particularly useful because the move generator doesn't take a significant amount of time anyway.

But the problem is that 'info string' is used both for messages you want to communicate to the user, as for extra output that is given in response to the 'debug' option being 'on' (and which you would likely want to appear only in some log). IMHO, this is a feature, not a problem. If a user encount...

Maybe a info comments .... sequence could be helpful in the protocol ? The "info string" sequence already allows any free form comments. If the issue is that the GUI shall not evaluate the strings in any way, the easiest solution would be not to send them. Extending UCI is pretty much out of questi...

Because I am a little scared by the following specification * if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string. "unknown command" refers to a full line ? or just a word ? The very next line in the UCI spec holds the answe...

I actually implemented it this way on purpose, since these are the official FIDE rules. For castling yes. But for capturing a piece, you can take first the piece and then place your own piece. It's just that the touch-move rule applies, i.e. if you touch an opponent's piece without announcing "j'ad...

Reasons: 1) most high-end dedicated units in the 80s were on Motorola 68k, but it was Intel's x86 who won the race. Mostly because 68k was used in home computers where most games wouldn't work with more than 68k at 8 MHz, so nobody bought faster models, so Motorola couldn't sell them. 2) once CPUs s...

RubiChess wrote: ↑

Fri Aug 02, 2019 4:15 am

It turns out that the call to getline(cin, inputsting) in the UCI input loop causes the segmentation fault

How does that even compile? According to http://man7.org/linux/man-pages/man3/getline.3.html , the prototype looks like this:

Maybe it would be a good idea to truncate overly long input lines at the earliest point possible to fix this once and for all. Besides, a server program crashing upon input data is a potential security vulnerability. The pasted line example is slightly more than 1 kB, so this looks like a promising ...