You want to be arrogant, seems you are qualified. Not once have I said I didn't have bugs in Crafty, I said the strcpy() code in ReadPGN() has worked forever, and still works everywhere but Apple. This "never makes a mistake" is YOUR straw man argument, not mine. When I intentionally work around undefined behavior, I am certain of the result. Whatever I might have done unintentionally was just that, unintentional.mvk wrote:Puhlease..... Crafty is full of buffer overflows. They are all over the place.bob wrote:There is ABSOLUTELY no way my use of strcpy() will break.
Ok, lets see:Or, on Linux:Code: Select all
crafty `python -c 'print 5000*"x"'` unable to open book file [/opt/local/share/crafty/book.bin] for "write". learning is disabled found computer opening book file [/opt/local/share/crafty/bookc.bin]. Abort trap: 6
Mind that on Debian this crap was patched downstream, in 2003...! But not upstream of course, because mr-know-it-all doesn't make bugs. It is ALWAYS somebody else's fault. Fact is, Crafty's use of strcpy(), and buffers in general, is not something to be proud of, and Apple in this case does a nice service to many of their customers to try out weed out programs written in this style from the eco system.Code: Select all
./crafty-235-64-ja `python 5000*"x"'` EPD Kit revision date: 1996.04.21 unable to open book file [./books.bin]. (info) command line option "xxxxxxxxxxxx [... snip ...] xxxxxx" Segmentation fault
P.S.: This thread, and the counterpart on open-chess, reminds me of one of the writing by one of my professors:
By that standard, you have a long way to go.EWD wrote:"We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers."
But carry on, I see no point in trying to discuss the point with you anyway, as in past cases...