A note for C programmers

[rreagan]

It's moot anyway. Already fixed. I am not sure what apple uses for their glibc. All my other systems don't have this problem, so it is either something very recent in glibc, or else it is an apple "addition".

Sounds like you're not comparing apples to apples...

[mvk]

It seems many implementations first determine the length of the string

This might not be what is happening. It seems glibc provides an optimised implementation if the string length is known at compile time.

What is happening is the following: OSX has a safety check. strcpy is mapped to _strcpy_chk. This detects if strcpy is used with overlapping memory areas. If so, it logs a message in the console and terminates the process, like this:

Code: Select all

23 Nov '13 7:23:38.406 PM str[84033]: detected source and destination buffer overlap
Abort trap: 6

This happens both with 'clang' and 'gcc'. (The real gcc. Note that the 'gcc' command is mapped to 'clang' by default).

The problem is not in the OS, as OP suggests, but in his own code. It contains a potential security problem and the OS catches it, protecting the user. The documentation of strcpy() is quite clear that areas shall not overlap. Even more, the function prototype is given as 'restrict' pointers.

Solution is to fix the application or replace it.

[syzygy]

Solution is to fix the application or replace it.

Or don't use an OS that decides what is best for you

[mvk]

Solution is to fix the application or replace it.

Or don't use an OS that decides what is best for you

Not possible for us addicted to the fruit. I'm already converting my engine to javascript to prepare for the next upgrade!

[bob]

It's moot anyway. Already fixed. I am not sure what apple uses for their glibc. All my other systems don't have this problem, so it is either something very recent in glibc, or else it is an apple "addition".

Sounds like you're not comparing apples to apples...

[lucasart]

What is happening is the following: OSX has a safety check. strcpy is mapped to _strcpy_chk. This detects if strcpy is used with overlapping memory areas. If so, it logs a message in the console and terminates the process, like this:

Code: Select all

23 Nov '13 7:23:38.406 PM str[84033]: detected source and destination buffer overlap
Abort trap: 6

This is a good thing. Code that does overlapping strcpy is so badly designed and ugly, that it deserves to be broken.

In the case of Crafty's ReadPGN() stuff, I still see no reason to do a copy. What Bob should have done instead is simply to use a pointer to parse the firt token, then make it point to the rest of the string and work with that pointer, incrementing with each token. Parsing sequentially is the way to go. The "eat a token and copy" algorithm is the kind of code that a complete beginner would write...

[bob]

What is happening is the following: OSX has a safety check. strcpy is mapped to _strcpy_chk. This detects if strcpy is used with overlapping memory areas. If so, it logs a message in the console and terminates the process, like this:

Code: Select all

23 Nov '13 7:23:38.406 PM str[84033]: detected source and destination buffer overlap
Abort trap: 6

This is a good thing. Code that does overlapping strcpy is so badly designed and ugly, that it deserves to be broken.

In the case of Crafty's ReadPGN() stuff, I still see no reason to do a copy. What Bob should have done instead is simply to use a pointer to parse the firt token, then make it point to the rest of the string and work with that pointer, incrementing with each token. Parsing sequentially is the way to go. The "eat a token and copy" algorithm is the kind of code that a complete beginner would write...

What on earth is so bad about copying the end of a string to the beginning? Yes there are other ways. This is a bit of code that was borrowed/converted from Cray Blitz, which is now over 40 years old. It worked forever. Changing the library to make it suddenly not work seems foolish when there is absolutely ZERO reason to do so. No way for a buffer overflow, no way for a security issue, no way for anything other than copying a shorter string into a buffer that currently holds a longer string..

The pointer idea is not so convenient. Because I can only read things in chunks, and when I near the end of the first chunk, I concatenate the next chunk with the small piece left in the buffer. A pointer would be more complex to avoid running out the end of the buffer.

As far as "a complete beginner" I am quite a bit beyond that...

[lucasart]

What on earth is so bad about copying the end of a string to the beginning?

It's a O(N^2) parsing algorithm, instead of O(N) for normal parsing. Plus it's ugly and relies on an undefined strcpy() behaviour, apparently (although I would never have guessed that strcpy() could be implemented right to left).

As far as "a complete beginner" I am quite a bit beyond that...

I do not doubt it. All you have to do is confess that you wrote a piece of newbie-like code 40 years ago

[mcostalba]

I do not doubt it. All you have to do is confess that you wrote a piece of newbie-like code 40 years ago

What is amazing to me is that there is 40 years old code still never touched. The fact that 'it works perfectly' is not a reason for me (perhaps I am a bit odd, but many software developers are odd too, they like to write software), I have fully rewritten many times entire parts of code even though it was working perfectly. Software is a live thing. If you don't maintain it, it slowly dies...even if it works perfectly.

[mvk]

What on earth is so bad about copying the end of a string to the beginning?

It's a O(N^2) parsing algorithm, instead of O(N) for normal parsing. Plus it's ugly and relies on an undefined strcpy() behaviour, apparently (although I would never have guessed that strcpy() could be implemented right to left).

As far as "a complete beginner" I am quite a bit beyond that...

I do not doubt it. All you have to do is confess that you wrote a piece of newbie-like code 40 years ago

At least Crafty is safe from PGN viruses now.

I love the claim that ReadPGN is supposedly two decades older than PGN, and the implication that Fortran has the equivalent of strcpy. All distracting from the bug, which was Crafty's alone. No, shoot the messenger instead.