strcpy() revisited

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: strcpy() revisited

Post by bob »

AlvaroBegue wrote:
bob wrote:There are dozens of PRNGs that use overflow (ignoring it, actually).
Then there are dozens of PRNGs that were written sloppily. Those same PRNGs should be written using unsigned integer types, whose overflow behavior is guaranteed by the standard.

I checked a first edition of K&R (published on 1978) and this distinction between overflow of signed and unsigned integer types was already there.
Still does NOT change the fact that they existed. Not every hardware platform supported unsigned ints, in fact.
Rein Halbersma
Posts: 741
Joined: Tue May 22, 2007 11:13 am

Re: strcpy() revisited

Post by Rein Halbersma »

bob wrote:
AlvaroBegue wrote:
bob wrote:There are dozens of PRNGs that use overflow (ignoring it, actually).
Then there are dozens of PRNGs that were written sloppily. Those same PRNGs should be written using unsigned integer types, whose overflow behavior is guaranteed by the standard.

I checked a first edition of K&R (published on 1978) and this distinction between overflow of signed and unsigned integer types was already there.
Still does NOT change the fact that they existed. Not every hardware platform supported unsigned ints, in fact.
And I'll bet there are still cars from those days without rear window break lights, or seat belts, air bags etc. that are legally required nowadays. That doesn't make those cars any safer to drive. In other words, upgrade your tools as time goes on.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: strcpy() revisited

Post by bob »

Rein Halbersma wrote:
bob wrote:
AlvaroBegue wrote:
bob wrote:There are dozens of PRNGs that use overflow (ignoring it, actually).
Then there are dozens of PRNGs that were written sloppily. Those same PRNGs should be written using unsigned integer types, whose overflow behavior is guaranteed by the standard.

I checked a first edition of K&R (published on 1978) and this distinction between overflow of signed and unsigned integer types was already there.
Still does NOT change the fact that they existed. Not every hardware platform supported unsigned ints, in fact.
And I'll bet there are still cars from those days without rear window break lights, or seat belts, air bags etc. that are legally required nowadays. That doesn't make those cars any safer to drive. In other words, upgrade your tools as time goes on.
Or, in your thinking, fix the traffic signals so that they recognize those older cars, change the signal to green for the opposite direction at the right time, and thereby get those old cars off the road by reducing them to a pile of junk.

I'd trade my ranger today for the 68 hemi roadrunner I owned, in a heartbeat. No shoulder seat belts. No airbags. No antilock brakes. No third brake light. Just a ton of power and a sound like no other. Those damned guys flying the old B17's, and P51d's and such ought to be forced to crash as well, get those old radar-less things out of the air... Not to mention all the old piper cubs, Cessna 172's, and other such ancient things.

In other words, I expect my mode of transportation to continue to work until _I_ decide to upgrade it. Not because I am forced to upgrade it. You drive a hybrid? I watched one crash and EXPLODE a few months back. No survivors. Shoot, crashing is "undefined behavior" right? No reason to "do the right thing"...
User avatar
hgm
Posts: 27808
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: strcpy() revisited

Post by hgm »

bob wrote:You drive a hybrid? I watched one crash and EXPLODE a few months back. No survivors. Shoot, crashing is "undefined behavior" right? No reason to "do the right thing"...
Well, that guy was asking for it. He had not fastened his seatbelt. The specs of the car did not mention what would happen if you turned the contact key without first fastening your seatbelt. Driving without seatbelt is illegal, right? So of course they programmed the car to explode when someone attempts that. That is just a safety measure, to increase the safety of everyone. He might have hurt himself, driving without seatbelt, and we would not want that, would we? If you ask for undefined behavior, you should get it! :lol:
wgarvin
Posts: 838
Joined: Thu Jul 05, 2007 5:03 pm
Location: British Columbia, Canada

Re: strcpy() revisited

Post by wgarvin »

hgm wrote:
bob wrote:You drive a hybrid? I watched one crash and EXPLODE a few months back. No survivors. Shoot, crashing is "undefined behavior" right? No reason to "do the right thing"...
Well, that guy was asking for it. He had not fastened his seatbelt. The specs of the car did not mention what would happen if you turned the contact key without first fastening your seatbelt. Driving without seatbelt is illegal, right? So of course they programmed the car to explode when someone attempts that. That is just a safety measure, to increase the safety of everyone. He might have hurt himself, driving without seatbelt, and we would not want that, would we? If you ask for undefined behavior, you should get it! :lol:
I may have a better car analogy to undefined behavior.

Relying on undefined behavior is like running back and forth across a busy highway, dodging through the cars. "That's illegal, don't do that", say the traffic police. "We have crosswalks for a reason. You're going to get hit by a car. Don't say we didn't warn you."

In that scenario, Bob's reply would be something like "I've been doing this every day since 1968, and I've never been hit by a car before. Any car who actually decides to hit me is stupid, since they can clearly see that I'm running across the road. Why do they not respect my clear intentions." But the compiler is more like minivans driven by a mother of three, distracted by her children. Or maybe like a Mack truck.

Programming languages have rules. The language spec spells out clearly what you can rely on, and what you can't. Programmers who want their programs to work, and keep working in the future, need to learn and follow those rules. They are not the rules of the x86 architecture, but a completely different set of abstract rules that might or might not make any sense. But we still have to follow them, or else accept that our programs will occasionally get hit by a Mack truck.
User avatar
hgm
Posts: 27808
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: strcpy() revisited

Post by hgm »

Not a very impressive analogy to someone living in Amsterdam, where I, as most other cyclists, ignore traffic lights by habit, and cross the road whenever I judge it safe. :wink:

But more seriously, I think the part that needs to be added to really make this an analogy to what we are talking about is:

"So starting now we decide to shoot everyone that makes it across the road alive, and we impose a hefty extra tax on car use to pay for their burrial."

Now who would still be happy with the law?
syzygy
Posts: 5566
Joined: Tue Feb 28, 2012 11:56 pm

Re: strcpy() revisited

Post by syzygy »

hgm wrote:Not a very impressive analogy to someone living in Amsterdam, where I, as most other cyclists, ignore traffic lights by habit, and cross the road whenever I judge it safe. :wink:

But more seriously, I think the part that needs to be added to really make this an analogy to what we are talking about is:

"So starting now we decide to shoot everyone that makes it across the road alive, and we impose a hefty extra tax on car use to pay for their burrial."

Now who would still be happy with the law?
I suppose you're talking specifically about Apple now. I would say it is more like "Starting from now we will arrest everybody that makes it across the road, so that they will realise their mistake before it kills them".

I might personally be in favour of "we don't care if they don't know what they're doing and end up killing themselves", but I can understand Apple's thinking. Apple does have something to lose if people release buggy insecure software.
User avatar
hgm
Posts: 27808
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: strcpy() revisited

Post by hgm »

Indeed that will be very effective. People would of course worry much more being arrested than they value their own life. And you forget to mention the part where the car drivers see their cost of driving doubled because of these measures... :lol:
syzygy wrote:..., but I can understand Apple's thinking. Apple does have something to lose if people release buggy insecure software.
Like aborting a program in an arbitrary place where it hits a not-often-executed strcpy that always worked in testing on other platforms would somehow guarantee security, and never do any damage, you mean?

It seems a safe bet that users will be hit by this infinitely more often than programmers. That will give Apple a really good name, if all that software that works perfectly on other platforms mysteriously aborts on Apple systems...
syzygy
Posts: 5566
Joined: Tue Feb 28, 2012 11:56 pm

Re: strcpy() revisited

Post by syzygy »

hgm wrote:Like aborting a program in an arbitrary place where it hits a not-often-executed strcpy that always worked in testing on other platforms would somehow guarantee security, and never do any damage, you mean?
Certainly a lot more secure than a program with a potential buffer overflow.

In general, programs that crash tends to get fixed. Crafty got fixed. That programs that sometimes give incorrect results get fixed is less likely.
It seems a safe bet that users will be hit by this infinitely more often than programmers. That will give Apple a really good name, if all that software that works perfectly on other platforms mysteriously aborts on Apple systems...
Still better than software with buffer overflows and strange behaviour.
User avatar
hgm
Posts: 27808
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: strcpy() revisited

Post by hgm »

Except that the programs that really suffered buffer overflow because of this already had been fixed long before. After all, doing a strcpy(a, b) as while(*a++ = *b++); can only end in two ways: either it works perfectly, or a lies within the sting b, and it will lead to an infinite repetitive string, certainly causing a segfault.

No buffer overflow would ever be caught by this measure that would not have segfaulted by itself.

It only makes a difference for the harmless cases, that worked absolutely correctly.