A note for C programmers

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A note for C programmers

Post by bob »

bnemias wrote:
bob wrote:It wasn't "undefined" when I started using C.
Most people when they see this, realize their code is assuming something it shouldn't. Perhaps like you they weren't aware of the overlapping restriction. Generally they just fix their code without making a big stink about it. Problem solved.

Perhaps this change is the precursor to a real implementation change on the horizon. And this was their way of preparing you for that change so you could easily track the problem.
I didn't "make a big stink about it." I pointed out Apple had done something stupid, namely to break it without saying a thing about doing so. It is ok to check for overlaps. And it would be ok to output an error message that indicated the problem. Not "Abort" period...

That is lousy software development policy. Lousy and arrogant. And unacceptable to me, which is why OS X is on life-support on my macbook, to be replaced by Linux this week if I have time.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A note for C programmers

Post by bob »

mvk wrote:
bob wrote:
mvk wrote:
bob wrote:On Apple Mavericks, all you see is "Abort". No hint about what the problem was, no nothing. Running under the debugger shows absolutely nothing either. Nice software design.
There is a message logged to the system log, as was mentioned before. Just open de Console application and read "crafty: detected source and destination buffer overlap". And then a nice readable crash report is saved in ~/Library/Logs/DiagnosticsReports/, containing, amongst others, a stack trace.
Fine. I am SURE every C programmer on the planet is aware of such. Makes a lot more sense than displaying an error message right out of the library like "Abort(source and destination strings overlap)". Let's put it in a non-obvious place and see if the programmer can find it.
The take home lesson, also nice for your students, is one can become more productive if one spends some time learning the tools one uses. In this case, syslog is a good place to look when a process has died unexpectedly.
Sorry, that's an ABNORMAL place to look for user program errors. In fact, on most systems, users don't have access to this data for lots of perfectly good reasons...

Doing it in an unusual way on mac os does NOT make it "correct" or "appropriate". I've been using Unix longer than anyone here and did not once think about looking in a log file or console error log to locate a _USER_ error.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A note for C programmers

Post by bob »

bnemias wrote:
bob wrote:
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.
Here is the key point.

"undefined" does NOT imply "the lib guys are suddenly going to start checking for overlapping addresses, and simply print "Abort" if it is detected. I consider that beyond lousy software development.
The irony here is that is exactly what you do in libraries to detect bugs in the calling code. And you consider that "beyond lousy."
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.
bnemias
Posts: 373
Joined: Thu Aug 14, 2008 3:21 am
Location: Albuquerque, NM

Re: A note for C programmers

Post by bnemias »

bob wrote:
bnemias wrote:
bob wrote:
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&#40;)  function	copies the string pointed to by src &#40;including
       the terminating '\0' character&#41; 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.

&#91;... snip ...&#93;

GNU				  1993-04-11			     STRCPY&#40;3&#41;
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.
Here is the key point.

"undefined" does NOT imply "the lib guys are suddenly going to start checking for overlapping addresses, and simply print "Abort" if it is detected. I consider that beyond lousy software development.
The irony here is that is exactly what you do in libraries to detect bugs in the calling code. And you consider that "beyond lousy."
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.
I know how to read, thank you. No need to get insulting.

You're right-- the message could have been better. Certainly I would have made the change more friendly to the library users had it been my job.

But this is the first time you indicate your beef was primarily with the message. You defended your bad code several times. That was the point I was arguing because it looked like you didn't get that it was assuming things it shouldn't.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A note for C programmers

Post by bob »

bnemias wrote:
bob wrote:
bnemias wrote:
bob wrote:
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&#40;)  function	copies the string pointed to by src &#40;including
       the terminating '\0' character&#41; 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.

&#91;... snip ...&#93;

GNU				  1993-04-11			     STRCPY&#40;3&#41;
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.
Here is the key point.

"undefined" does NOT imply "the lib guys are suddenly going to start checking for overlapping addresses, and simply print "Abort" if it is detected. I consider that beyond lousy software development.
The irony here is that is exactly what you do in libraries to detect bugs in the calling code. And you consider that "beyond lousy."
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.
I know how to read, thank you. No need to get insulting.

You're right-- the message could have been better. Certainly I would have made the change more friendly to the library users had it been my job.

But this is the first time you indicate your beef was primarily with the message. You defended your bad code several times. That was the point I was arguing because it looked like you didn't get that it was assuming things it shouldn't.
I don't consider something that has worked forever as "bad code" when ONE vendor decides to enforce something that has never been a problem in the first place.

I get "deprecated" messages all the time. Intel decides to delete a compiler option. Rather than just breaking it and causing the compiler to stop, they produce a deprecated warning, giving everyone time to see what option change is necessary to avoid issues in upcoming releases.

Quite simply, "don't break something capriciously, break it for a reason." Here there's no reason. "undefined" does not mean "crash on the spot." There's no way Apple can enforce software security with some lame attempt to avoid buffer overwrites. They don't check the read byte count limit against the buffer size, they can't. This was a stupid change.
Rein Halbersma
Posts: 741
Joined: Tue May 22, 2007 11:13 am

Re: A note for C programmers

Post by Rein Halbersma »

bob wrote: "undefined" does not mean "crash on the spot."
Wrong, according to the C Standard, undefined behavior can mean "crash on the spot" albeit with a diagnostic (underlined my emphasis)

http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A note for C programmers

Post by bob »

Rein Halbersma wrote:
bob wrote: "undefined" does not mean "crash on the spot."
Wrong, according to the C Standard, undefined behavior can mean "crash on the spot" albeit with a diagnostic (underlined my emphasis)

http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Apple FORCED it to be "crash on the spot" with no error, no warning, no nothing, and changed the behavior between Mountain Lion and Mavericks. Completely unacceptable. I'm "voting with my feet" and (a) won't buy future Apple products, and (b) am installing Linux on my macbook as soon as I have time...

this isn't a "security issue". What do they intend to do when I do this:

strcpy(a, b);

where b is MUCH longer than a? No way to tell how long a is, if it is declared in a different file/procedure. That will overwrite.

For overlapping, the issue becomes "end-of-string sentinel" which they ALSO have no idea where it is located. Why fix one by absolutely breaking it so it never works, and ignore the other, which is a more common issue anyway?

Poor. REALLY poor.
Rein Halbersma
Posts: 741
Joined: Tue May 22, 2007 11:13 am

Re: A note for C programmers

Post by Rein Halbersma »

bob wrote:
Rein Halbersma wrote:
bob wrote: "undefined" does not mean "crash on the spot."
Wrong, according to the C Standard, undefined behavior can mean "crash on the spot" albeit with a diagnostic (underlined my emphasis)

http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Apple FORCED it to be "crash on the spot" with no error, no warning, no nothing, and changed the behavior between Mountain Lion and Mavericks. Completely unacceptable. I'm "voting with my feet" and (a) won't buy future Apple products, and (b) am installing Linux on my macbook as soon as I have time...

this isn't a "security issue". What do they intend to do when I do this:

strcpy(a, b);

where b is MUCH longer than a? No way to tell how long a is, if it is declared in a different file/procedure. That will overwrite.

For overlapping, the issue becomes "end-of-string sentinel" which they ALSO have no idea where it is located. Why fix one by absolutely breaking it so it never works, and ignore the other, which is a more common issue anyway?

Poor. REALLY poor.
A frozen pond is a good example of an undefined walking surface. Just because you make it across once doesn't mean you should add the shortcut to your paper route, especially if you're planning for the four seasons.
mvk
Posts: 589
Joined: Tue Jun 04, 2013 10:15 pm

Re: A note for C programmers

Post by mvk »

Rein Halbersma wrote:A frozen pond is a good example of an undefined walking surface. Just because you make it across once doesn't mean you should add the shortcut to your paper route, especially if you're planning for the four seasons.
Valgrind also catches this specific case of undefined behaviour. Many programmers already improved their code because of valgrind. The offending code can easily be bypassed:

Code: Select all

memmove&#40;buf, buf+n, strlen&#40;buf+n&#41;);
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A note for C programmers

Post by bob »

Rein Halbersma wrote:
bob wrote:
Rein Halbersma wrote:
bob wrote: "undefined" does not mean "crash on the spot."
Wrong, according to the C Standard, undefined behavior can mean "crash on the spot" albeit with a diagnostic (underlined my emphasis)

http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Apple FORCED it to be "crash on the spot" with no error, no warning, no nothing, and changed the behavior between Mountain Lion and Mavericks. Completely unacceptable. I'm "voting with my feet" and (a) won't buy future Apple products, and (b) am installing Linux on my macbook as soon as I have time...

this isn't a "security issue". What do they intend to do when I do this:

strcpy(a, b);

where b is MUCH longer than a? No way to tell how long a is, if it is declared in a different file/procedure. That will overwrite.

For overlapping, the issue becomes "end-of-string sentinel" which they ALSO have no idea where it is located. Why fix one by absolutely breaking it so it never works, and ignore the other, which is a more common issue anyway?

Poor. REALLY poor.
A frozen pond is a good example of an undefined walking surface. Just because you make it across once doesn't mean you should add the shortcut to your paper route, especially if you're planning for the four seasons.
No, but if the temp hasn't changed, weather hasn't changed, there's no reason for the thickness of the ice to mysteriously change. But even then, I will know what happened. This is more like walking across the ice and being mysteriously transported across the planet somewhere with no warning whatsoever.

You are STILL missing the point. Apple INTENTIONALLY broke the code, WITHOUT giving any warning, and WITHOUT giving any useful explanation other than "Abort" which is a lousy way of doing business. I simply choose to not tolerate this, period.