A note on strcpy

[User923005]

I compiled them as separate files. I even attached them. The only thing I changed in the second example is the value passed to the function in main, which was in a separate file.
Look, if you want to use undefined behavior as a feature of your programs -- be my guest.
I won't argue about it any longer.
It is clear to me that relying on undefined behavior when perfectly good alternatives exist is a very bad idea.
I won't try to convince you any more. It is clearly a complete waste of time.
You are a good programmer and a big help to many in the chess community. But once you have your mind made up about something there is no amount of reason that will change it.
That is fine. I know plenty of people like that, including some people who are related to me.
I love them anyway.
I can be hard to convince as well, and so I don't need to try to beat my chest about it.
I am wrong from time to time, but I like to think that I can admit it when I am mistaken.
I hope I am not wrong about that.

[lucasart]

I won't try to convince you any more.

Exactly. Perhaps you haven't noticed yet, but it's pointless arguing with Bob. He just has to have the last word, especially when he's wrong.

Same pointless discussion was held on talkchess. Basically his whole argumentation is based on the axiom that his code is right, and the C standard is wrong...

A simple case of RTFM:

Code: Select all

$ man strcpy
...The strings may not overlap, and the destination string dest must be large enough to receive the copy.  Beware of  buffer overruns!

PS: I'm also very amused about Bob's claim that the offending code is over 40 years old. Let me do that math: that means 1973 or before, at which point the C language did not even exist, unless Bob Hyatt was working with Denis Ritchie and Ken Thompson at Bells lab, co-creating C and UNIX.

[hyatt]

So you are telling me that the compiler can somehow read your mind when compiling dodo and that it KNOWS that you passed a 1 or a 0? Please get serious. I just created a tst1.c and tst2.c exactly as you had them. I compiled tst1.c and then tst2.c. I set the argument to the function to 0 and then 1. I compiled with gcc 4.7.3, clang, and MSVC. None of 'em could figure out what was going on here on the versions I used... Nor would I as a compiler person expect them to, because when I compile the function I have no idea what the value of the argument is...

As far as the "undefined" here is something I watched on TV this morning that reminded me of what YOU might do...

I watched a video where a Boeing 777 was having to land in a really severe crosswind. A crosswind stronger than the max recommended by Boeing. The plane was low on fuel and had absolutely no choice. The problem is simple (I learned to fly 45 years ago so I have done this, just not in a commercial jet). Let's make this crosswind right to left across the runway. 30mph max safe crosswind. Currently the wind is 45mph. To fly parallel to the runway, you have to hold enough right rudder to "crab" into the wind, and you have to hold enough left aileron to keep the wings level. The problem is that the left wing (facing toward the direction of travel) has more left than the trailing wing, so by holding left aileron, you increase the camber of the right wing to equalize lift. Manufacturers state a max crosswind allowance because as the plane crabs, the body of the plane actually "shields" the trailing wing making it hard to hold the right side of the plane up (and level). Hence the max recommended crosswind of 30mph. Anything beyond that produces "undefined behavior" due to the complex interaction of angle of attack, aileron setting, crab angle, etc. Your company would think "OK if we reach this undefined point" we are going to simply center the ailerons since the behavior is undefined. And you stick the airplane in the ground. 290 people dead. Only problem was, the pilot was good. He knew that he could exceed the crosswind recommendation if he simply increased airspeed (roughly proportional to sine (crab angle). Landing a little "hot" is perfectly acceptable. You decided that undefined meant "crash".

Nice logic.

I'm sure the families of the victims would support your way of thinking with no lawsuits forthcoming.

[hyatt]

I won't try to convince you any more.

Exactly. Perhaps you haven't noticed yet, but it's pointless arguing with Bob. He just has to have the last word, especially when he's wrong.

Same pointless discussion was held on talkchess. Basically his whole argumentation is based on the axiom that his code is right, and the C standard is wrong...

A simple case of RTFM:

Code: Select all

$ man strcpy
...The strings may not overlap, and the destination string dest must be large enough to receive the copy.  Beware of  buffer overruns!

PS: I'm also very amused about Bob's claim that the offending code is over 40 years old. Let me do that math: that means 1973 or before, at which point the C language did not even exist, unless Bob Hyatt was working with Denis Ritchie and Ken Thompson at Bells lab, co-creating C and UNIX.

1. Cray Blitz was fortran. I didn't say the CODE itself was in use back then. I said that parsing approach. I simply translated from Fortran, which had no strings back in the day, to C. Is that too hard to follow. In fortran all we had was arrays. Arrays of integers in this case. I wrote my own "string functions" as a result. And my string copy copied left to right, but I passed a byte count to it rather than terminating strings with a zero. Seemed perfectly logical to do that back in those days.

2. I've not said my programming is correct. I have said Apple was WRONG for breaking this. The way I used strcpy() is 100% safe, even if the oft-repeated mantra "undefined is undefined" is repeated even more. Making it fail intentionally, with absolutely no benefit (and even a performance loss in fact) is stupid. They COULD have fixed it. Since they catch overlapping pointers, they could have re-directed it to memmove() and now they have done something that is actually useful. They just broke it.

3. I WAS running unix in 1976, for the record, on a PDP-11 that was given to me by our speech department. I was talking about the machine with Ken Thompson at the 1976 ACM event and he promptly sent me a DecTape with Unix on it. CMU was running Unix at the same time. As were others. Sorry to burst your bubble.

My complaint is with Apple breaking something that worked. Nobody else has done this. Which simply convinced me that OS X has to go. And it will, soon.

[Chris Whittington]

I won't try to convince you any more.

Exactly. Perhaps you haven't noticed yet, but it's pointless arguing with Bob. He just has to have the last word, especially when he's wrong.

Same pointless discussion was held on talkchess. Basically his whole argumentation is based on the axiom that his code is right, and the C standard is wrong...

A simple case of RTFM:

Code: Select all

$ man strcpy
...The strings may not overlap, and the destination string dest must be large enough to receive the copy.  Beware of  buffer overruns!

PS: I'm also very amused about Bob's claim that the offending code is over 40 years old. Let me do that math: that means 1973 or before, at which point the C language did not even exist, unless Bob Hyatt was working with Denis Ritchie and Ken Thompson at Bells lab, co-creating C and UNIX.

1. Cray Blitz was fortran. I didn't say the CODE itself was in use back then. I said that parsing approach. I simply translated from Fortran, which had no strings back in the day, to C. Is that too hard to follow. In fortran all we had was arrays. Arrays of integers in this case. I wrote my own "string functions" as a result. And my string copy copied left to right, but I passed a byte count to it rather than terminating strings with a zero. Seemed perfectly logical to do that back in those days.

2. I've not said my programming is correct. I have said Apple was WRONG for breaking this. The way I used strcpy() is 100% safe, even if the oft-repeated mantra "undefined is undefined" is repeated even more. Making it fail intentionally, with absolutely no benefit (and even a performance loss in fact) is stupid. They COULD have fixed it. Since they catch overlapping pointers, they could have re-directed it to memmove() and now they have done something that is actually useful. They just broke it.

3. I WAS running unix in 1976, for the record, on a PDP-11 that was given to me by our speech department. I was talking about the machine with Ken Thompson at the 1976 ACM event and he promptly sent me a DecTape with Unix on it. CMU was running Unix at the same time. As were others. Sorry to burst your bubble.

My complaint is with Apple breaking something that worked. Nobody else has done this. Which simply convinced me that OS X has to go. And it will, soon.

I refer you to Taleb, Anti-Fragile. Where ROBUST system=absorb shock and stay the same. ANTIFRAGILE system=absorb shock and get better.

By trapping ANY potential problem where a programmer has doing something outside the documented spec, Apple are increasing the robustness of the system. This is good for the greater system of Apple reliabilty and end user confidence, if it bugs a programmer, then so be it.

Apple don't know who is sitting in front of the screen. Could be the programmer, a tester, an end-user. The problem program should be aborted and non-technical end users should not be freaked with weird error messages. If the problem gets reported back to the programming team or QA team, they can ask for the log file or try and reproduce and fix it.

If this results in the programmer fixing the problem and being prompted to think about other similar problems in his code, perhaps in other programs too, then the system in general gets better, as a result of the shock. Here the system being seen as apple computers, developers and end users.

If, as an alternative, this results in the programmer throwing a hissy fit, casting blame at others, trying to persuade other programmers and students to continue with bad habits, and junking all further work on Apple products, then this self-culling is good too. The system gets better as a result of the shock by the elimination of rogue programmers who consider themselves special cases and thus fewer future shock events. Anti-fragile system in both cases.

It's a developing, changing, complex system, and the best programmers are those who consider themselves and others on the system as equals, no blame, a culture of preemption of problems. Read the documentation, stick to the specification, don't trample on stuff outside your box, think about other users/applications that call/use you and find ways, if you can, to deal with potentially rogue inputs.

If you are a program manager, identify the "types" of programmer you manage, encourage them, retrain them or fire them as appropriate. Don't allow your programmers to manage you.

[hyatt]

1. This broke tens of thousands of programs that were working correctly.

2. This broke them SILENTLY with no clue about what was going on. Just the "Abort" that was printed out, no explanation, no nothing.

3. There is no valid reason for breaking programs that are working, just because they violate a "rule" that should not be there in the first place. The only issue with strcpy() and overlapping strings has been well-documented over the years. As similar functions were in other languages. Simply don't code "strcpy(st+n, st); That doesn't eliminate all errors, neither does the overlapping string test. Source can be longer than destination. Source might not have null terminator again making it longer than destination. User can screw up with the st+n stuff and accidentally make the source start beyond the terminator. User can pass a null string pointer for either argument. User can pass a destination that was declared as const and placed in the read-only area of memory. In short, there are many ways to make a program crash with strcpy(). There are many ways to cause bugs that don't make it crash, but which do make it produce incorrect results. And there are ways to overlap with zero problems.

I would not have minded had the thing said "Warning, overlapping strings is dangerous, and is going to be eliminated in a future release." I get deprecated compiler option warnings all the time from both Intel and GCC. And I look to see what is preferred instead of the option that is being phased out, and fix it. But the way Apple did this simply caused me to waste a week of time looking for a bug in the last released version that simply was not there. I consider that unacceptable. And I vote the way I always vote, if I don't like a product, I don't buy it. In this case, I am going to replace os x with linux, which works just fine, still. MANY are unhappy with Apples change. You can find lots of discussions about it. They slowed the code down, because there is no simple way to detect overlap with a null-terminated string, since you don't know where it ends until you find it. Code is slower, it breaks existing programs, not a good software development approach.

[User923005]

So you are telling me that the compiler can somehow read your mind when compiling dodo and that it KNOWS that you passed a 1 or a 0? Please get serious. I just created a tst1.c and tst2.c exactly as you had them. I compiled tst1.c and then tst2.c. I set the argument to the function to 0 and then 1. I compiled with gcc 4.7.3, clang, and MSVC. None of 'em could figure out what was going on here on the versions I used... Nor would I as a compiler person expect them to, because when I compile the function I have no idea what the value of the argument is...
{snip}

Yes, that is exactly what I am telling you.
I supplied the actual source files that I used. The only change between sessions was changing the 0 to 1 in main.
We have the gazillion dollar version of Visual Studio and it does data flow analysis for the entire project.
I am sure that the Intel compiler will do the same thing.
I suspect that gcc will also perform this action if used properly, though I admit I do not know how to perform data flow analysis with gcc.

[User923005]

Attached are screen images

[User923005]

To get the deepest analysis, you configure analysis for the solution to use all rules, and then run code analysis on the solution.

[Jeremy Bernstein]

I have to say, I find it pretty appalling that a CS professor, a "compiler guy", would insist that a code style which is documented to produce undefined behavior (where the compiler guys are under no obligation to do _anything_ -- they could write "poop\0" into the destination string if they wanted, and it would be compliant) as correct, and make accusations and absurd justifications in multiple directions when that stance is questioned. All due respect for your life work, Bob, but that's pretty untenable. I realize I'm just adding fuel to the fire in saying so, but wrong is wrong. I'm grateful to Apple for enforcing the spec, personally, despite real man-hours I've spent dealing with the problem.

jb