bob wrote:Where do you look in a program that is working on every other machine, and has for years, and suddenly just says "Abort" and returns to the shell prompt on Mavericks?
My suggestion would be to start it under the debugger and put a breakpoint on the abort function, and look at the stack trace. Of course I may be spoiled by having access to an actual easy-to-use debugger in Visual Studio.
mvk wrote:bob wrote:
Please return to the docs of the 80's or 90's and look at the man page for strcpy().
I don't re-read man pages every few weeks...
Code: Select all
DESCRIPTION
The strcpy() function copies the string pointed to by src (including
the terminating '\0' character) to the array pointed to by dest. The
strings may not overlap, and the destination string dest must be large
enough to receive the copy.
[... snip ...]
GNU 1993-04-11 STRCPY(3)
K&R 1988 says the same:
K&R wrote:B3. String functions: <string.h>
...
Except for memmove, the behavior is undefined if copying takes place between overlapping objects.
"Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to having demons fly out of your nose."
You have to put aside your knowledge of how strcpy is implemented and consider it rationally. As MVK pointed out this has been clearly documented as undefined behavior for at least 25 years, just like memcpy. And anybody using memcpy for overlapping copies clearly deserves what they get, because
the spec says its undefined... why should strcpy be different?
Of course its annoying to find a latent bug like that in code you wrote so long ago, but I don't think its fair to blame the library vendor in a case like this.
For 25 years the languages spec has
promised you that your program might break on some platform, if you relied on this behavior. Finally it did!
And now to play Devil's advocate:
Like almost everyone else, I end up relying on undefined behavior all the time in my own programs too, sometimes even on purpose (!), its pretty difficult to completely avoid it. e.g. as far as I know null pointers are not guaranteed to be represented by all-zero-bits, yet I memset pointer-containing structures to zero just like everybody else does. Signed-integer overflows and pointer-arithmetic overflows are rampant in production code, as are platform-specific assumptions about 2's complement representation and bit-shift operands, theoretically-unsafe type puns and other strict-aliasing violations, and many other problems of that sort. Most of the time the programmers writing that code don't understand that its unsafe; sometimes they do understand all those rules and and just don't realize they are writing code that breaks them (and thus has undefined semantics), and in some rare cases they DO realize they are writing it but its expedient to do it anyway for some reason, perhaps they just have no other way to make the compiler do what they want. There are apparently almost 200 types of undefined behavior in C99, and I don't want to even guess how many there are in C++.
The world could really use a better-designed (and safer) systems programming language, but it doesn't seem likely anything suitable will ever reach the popularity of C and C++, at least not anytime soon!