A note for C programmers

[bnemias]

Please learn to read first. I said "not just print ABORT" with absolutely no explanation as to why the thing is aborting. A reasonable error message (strcpy() called with overlapping string pointers, aborting.") would be just fine. Not just "Abort". 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?

That is "beyond lousy" absolutely.

It's really hard to know why you are having issues with this. You've flip-flopped from defending your code, to complaining that the error message was the problem, and back to defending your code.

Which is it?

[bob]

Please learn to read first. I said "not just print ABORT" with absolutely no explanation as to why the thing is aborting. A reasonable error message (strcpy() called with overlapping string pointers, aborting.") would be just fine. Not just "Abort". 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?

That is "beyond lousy" absolutely.

It's really hard to know why you are having issues with this. You've flip-flopped from defending your code, to complaining that the error message was the problem, and back to defending your code.

Which is it?

I have not flip-flopped at all.

My ORIGINAL post pointed out that something that worked on Mountain Lion now fails on Mavericks. As I tracked it down I gave details. I also pointed out that it has worked on EVERY operating system, EVERY compiler, since the early days of Crafty. And that suddenly, on Mavericks, it fails. With an error message that says absolutely nothing.

I see absolutely nothing wrong with my code. I do not run a risk of string overrun, which could happen if the arguments were reversed, or if the second unintentionally started beyond the actual end-of-string null. Neither can happen. I see no reason for it to suddenly stop working. Absolutely none. Good code. Bad code. Main thing is "working code" where no conditions have changed except for the library stuff added by Apple. POORLY added by Apple.

I see no valid reason to break working code, particularly when there is no reason to do so, and particularly when the change doesn't explain the problem, just says "Abort". How hard is that to follow, really?

Is the code very old? Yep. Could it be a problem? Somewhere, somehow, possibly, given some computer architectural detail in handling strings that is not an issue today or at any point in the past history of computing. Does it make sense to do what Apple did? Absolutely not. If you don't agree, that's fine. We simply have different standards on software changes in that case. I don't believe you should break something solely because you can.

[bob]

I've looked at some glibc comments and actual source code. As I thought, the "undefined" behavior is "defined" for one specific case:

char st="abcdefghi"

strcpy(&st[4], &st[0]);

The potential problem with overlaps, like the above, and ONLY like the above, is that you might overwrite part of the destination, before it is copied.

st[4]=st[0];
st[5]=st[1];
st[6]=st[2];
st[7]=st[3];
st[8]=st[4] (which is now st[0], st[4] has been lost. Etc. The intent of the above would be to get something like this:

st="abcdabcdefghi"

I would presume. But in reality, it would end up

st="abcdabcdabcd...." which would overflow since the terminating null keeps getting overwritten as it walks through memory. I agree that's stupid.

I didn't do that and would not make that kind of mistake. My code copies in a way that absolutely can not fail unless the strcpy() function decides to copy right to left for unknown reasons.

Apple is drawing a lot of customer complaints about this...

[bnemias]

My ORIGINAL post pointed out that something that worked on Mountain Lion now fails on Mavericks. (...) I also pointed out that it has worked on EVERY operating system, EVERY compiler, since the early days of Crafty. And that suddenly, on Mavericks, it fails.

Right, and everyone ignores that for good reason. Several people have shown that your code makes assumptions about how strcpy() is implemented. That you haven't encountered library problems for 40 years is simply not relevant.

I see absolutely nothing wrong with my code.

I know you don't. You are wrong, your code was flawed.

I see no valid reason to break working code, particularly when there is no reason to do so

You keep asserting that there was no valid reason. That doesn't make it so.

, and particularly when the change doesn't explain the problem, just says "Abort".

I agree the message wasn't very helpful, and should have included more to simplify your detection of the problem.

Does it make sense to do what Apple did? Absolutely not. If you don't agree, that's fine.

How can I agree or disagree? I have no evidence, just your insistence that there was no valid reason.

I should add that it doesn't matter if there was a valid reason. The code was still flawed regardless. If it turns out that there was no valid reason, then the lib guys were jerks, yes. But it doesn't absolve your code's dependence on undefined behavior.

[mvk]

I should add that it doesn't matter if there was a valid reason. The code was still flawed regardless. If it turns out that there was no valid reason, then the lib guys were jerks, yes. But it doesn't absolve your code's dependence on undefined behavior.

OSX doesn't use glibc of course. (Although glibc also has fortification functionality.)

With the OSX libs, there is a way out provided for broken programs: First, old compiles are not impacted. Second, for new compiles, and if one insists on relying on undefined behaviour (but why?), it is a matter of setting a compiler option when compiling the flawed program (-U_FORTIFY_SOURCE -O).

[syzygy]

I should add that it doesn't matter if there was a valid reason. The code was still flawed regardless. If it turns out that there was no valid reason, then the lib guys were jerks, yes. But it doesn't absolve your code's dependence on undefined behavior.

OSX doesn't use glibc of course. (Although glibc also has fortification functionality.)

With the OSX libs, there is a way out provided for broken programs: First, old compiles are not impacted. Second, for new compiles, and if one insists on relying on undefined behaviour (but why?), it is a matter of setting a compiler option when compiling the flawed program (-U_FORTIFY_SOURCE -O).

OSX fortifies by default? Yuck.

[mvk]

OSX fortifies by default? Yuck.

That is not different from linux.

Code: Select all

uname -s
Linux
gcc -dM -E - </dev/null | grep FORTIFY
#define _FORTIFY_SOURCE 2

[syzygy]

OSX fortifies by default? Yuck.

That is not different from linux.

Code: Select all

uname -s
Linux
gcc -dM -E - </dev/null | grep FORTIFY
#define _FORTIFY_SOURCE 2

It certainly is different from my Linux...

[mvk]

OSX fortifies by default? Yuck.

That is not different from linux.

Code: Select all

uname -s
Linux
gcc -dM -E - </dev/null | grep FORTIFY
#define _FORTIFY_SOURCE 2

It certainly is different from my Linux...

That was Ubuntu 10.04. I also checked Ubuntu 12.04 and it says the same.

[ The latter is now testing my simple-minded Syzygy bases hack BTW. WDL only, probed in search from SSD. 6pc. No DTZ yet. Prune draws, don't prune but give bonus for wins. So far scoring 56% vs. the previous version (which already had 5pc draw-bases), after 1409 games and counting: +450-295=664 ]

[syzygy]

This was Ubuntu 10.04. I also checked Ubuntu 12.04 and it says the same.

Mine is Fedora.

[ The later one is now testing my simple-minded Syzygy bases hack BTW. WDL only, no DTZ yet. So far scoring 56% vs. the previous version (which already had 5pc draw-bases), after 1409 games and counting: +450-295=664 ]

That's a lot...