strcpy() revisited

[wgarvin]

I've grown up in an era of trusting the compiler. You got a bug, it is almost certainly a programming bug. That era seems to be coming to an end, because a change to a compiler really should not change program behavior, if the original compiler was worth a crap...

Yet we are seeing exactly that...

Yeah, its pretty depressing. But the compiler writers seem to adamantly believe they are making their compilers better, not worse. And they even have some halfway-decent arguments.

I hope the situation will get better in the future, but I don't know how it will happen. Unless the standards committee or academic researchers can prod them into doing it, the compiler guys are probably not going to create the "safer" language variants and compilers that I would rather be programming with.

[bob]

I've grown up in an era of trusting the compiler. You got a bug, it is almost certainly a programming bug. That era seems to be coming to an end, because a change to a compiler really should not change program behavior, if the original compiler was worth a crap...

Yet we are seeing exactly that...

Yeah, its pretty depressing. But the compiler writers seem to adamantly believe they are making their compilers better, not worse. And they even have some halfway-decent arguments.

I hope the situation will get better in the future, but I don't know how it will happen. Unless the standards committee or academic researchers can prod them into doing it, the compiler guys are probably not going to create the "safer" language variants and compilers that I would rather be programming with.

Although you would think that the standards guys could lock the standards down just a bit better. Too many "left up to the implementation" or "undefined behavior" cases to make it read like a real standard. I've not looked at the POSIX standard for Unix in a good while, but I don't remember that many of those "whatever" things...

[lucasart]

Bla bla bla...

Perhaps you should listen to Marco's advice: use Valgrind, fix your code, and stop spamming the forum.

If you want to fix the C standard instead of your code, talkchess is not the place to do it. You can argue your points endlessly, and even if the whole of talkchess agrees with you (unlikely), the C standard will still remain unchanged. I suppose you could join the C standard comittee and make some concrete proposals there.

It seems this strcpy() discussion is going to break the world spamming record:
* 34 pages in the initial thread
* 4 in this one, but will surely grow very quickly
* 7 pages of the same stuff on open-chess forum too

With a bit more effort we can easily pass the 100 pages of spam.

[wgarvin]

It seems this strcpy() discussion is going to break the world spamming record:
* 34 pages in the initial thread
* 4 in this one, but will surely grow very quickly
* 7 pages of the same stuff on open-chess forum too

You can always ignore the thread. The discussion has been interesting, maybe a bit heated sometimes, but that's not unusual for talkchess.

Anyway, I think we've sort of agreed to disagree about the undefined behavior. I don't intend to keep posting about it. I do think its something everyone who programs in C or C++ ought to be aware of. But its not that hard to avoid undefined behavior in your programs (at least most of the time), you just have to stick to sensible stuff and be wary of a few things like signed integer overflow, bit-shifts of signed values, and so on.

There's tons of programmers out there writing tons of code every day and most of that code is legal according to the standard. At the same time, it does have a few dark corners, and in there be dragons!!

[Codesquid]

I've grown up in an era of trusting the compiler. You got a bug, it is almost certainly a programming bug.

Undefined behavior in your program is a programming bug.

That era seems to be coming to an end, because a change to a compiler really should not change program behavior, if the original compiler was worth a crap...

See it the other way around: Different compilers expose different bugs in your program, thus increasing overall quality if those bugs are fixed.

[Daniel Shawul]

It seems this strcpy() discussion is going to break the world spamming record:
* 34 pages in the initial thread
* 4 in this one, but will surely grow very quickly
* 7 pages of the same stuff on open-chess forum too

You can always ignore the thread. The discussion has been interesting, maybe a bit heated sometimes, but that's not unusual for talkchess.

Anyway, I think we've sort of agreed to disagree about the undefined behavior. I don't intend to keep posting about it. I do think its something everyone who programs in C or C++ ought to be aware of. But its not that hard to avoid undefined behavior in your programs (at least most of the time), you just have to stick to sensible stuff and be wary of a few things like signed integer overflow, bit-shifts of signed values, and so on.

There's tons of programmers out there writing tons of code every day and most of that code is legal according to the standard. At the same time, it does have a few dark corners, and in there be dragons!!

Lucas is absolutely right. Remember this is not a chess programming discussion so strcpy() is nothing but spam. Dissecting strcpy() belongs to stackoverflow, which you all have cited many discussions from (A big hint). But no, we have to endure this spam, because we have to find out who has longest programing ----.

[michiguel]

It seems this strcpy() discussion is going to break the world spamming record:
* 34 pages in the initial thread
* 4 in this one, but will surely grow very quickly
* 7 pages of the same stuff on open-chess forum too

You can always ignore the thread. The discussion has been interesting, maybe a bit heated sometimes, but that's not unusual for talkchess.

Anyway, I think we've sort of agreed to disagree about the undefined behavior. I don't intend to keep posting about it. I do think its something everyone who programs in C or C++ ought to be aware of. But its not that hard to avoid undefined behavior in your programs (at least most of the time), you just have to stick to sensible stuff and be wary of a few things like signed integer overflow, bit-shifts of signed values, and so on.

There's tons of programmers out there writing tons of code every day and most of that code is legal according to the standard. At the same time, it does have a few dark corners, and in there be dragons!!

Lucas is absolutely right. Remember this is not a chess programming discussion so strcpy() is nothing but spam. Dissecting strcpy() belongs to stackoverflow, which you all have cited many discussions from (A big hint). But no, we have to endure this spam, because we have to find out who has longest programing ----.

[MODERATION]
We received complaints before and the mod team decided to allow the thread to go on. Probably a good decision, illustrated by the fact that a clearly on-topic and interesting thread branched from it ("How could a compiler..."). However, now we have two other threads (strcpy and a note to C programmers), rather than one. Not clear this was necessary.

So, can we trust in the good will and good sense of the people? would it be possible that the people who is annoyed by this thread ignore it for a couple of days, and, at the same time... would it be possible to wrap this up in a couple of days? Keeping it in one thread might not be a bad idea either. Meanwhile, the mod team may need to talk to see if the original decision should change or not.

Miguel
PS: Please, do not respond to this message. We certainly do not need to hijack the thread. That would cause undefined behavior.

[hgm]

Then you should use a compiler that makes a promise that it will deal with integer overflow in a particular way. For gcc, just get used to invoking it with -fwrapv. I'm sure you won't mind the loss in efficiency, especially on loops using an int as loop variable.

Ah, it is good to know that this destructive behavior can be switched off. And of course there won't be any loss in efficiency whatsoever, as I would never write any code that could benefit from 'code-wrecking optimizations'.

I would not write "for(i=1; i>=0; i += i)" when I meant "while(1)". I wonder how many people would... So making the compiler assume this was meant, no matter by which amount of contrived reasoning, doesn't count as sane behavior, IMO.

[mar]

I learned a couple of things thanks to these threads, namely that I will never do shifts of signed integers again and that I can't rely on the order of execution of statements, no matter if they access volatile variables or not.
OTOH there are threads that give me absolutely nothing yet I wouldn't call them spam just because they're not interesting to me.

[Rein Halbersma]

I learned a couple of things thanks to these threads, namely that I will never do shifts of signed integers again and that I can't rely on the order of execution of statements, no matter if they access volatile variables or not.
OTOH there are threads that give me absolutely nothing yet I wouldn't call them spam just because they're not interesting to me.

Avoiding shifting on signed integers is probably a good rule of thumb. E.g. to use shifting on signed integers in order to get cheaper multiplications and divisions is something that your compiler will already do for you (and if it doesn't, it's probably not worthwhile anyway).

But note that not shifting signed integers at all it is slightly more restrictive than necessary. Shifting positive values by valid shift amounts is typically OK, and only if you shift negative signed values do you land in undefined (for left-shifts) or implementation-defined (for right-shifts) behavior. E.g. the C++ Standard has this clause

Code: Select all

5.8 Shift operators [expr.shift]
1 The shift operators << and >> group left-to-right.
    shift-expression:
        additive-expression
        shift-expression << additive-expression
        shift-expression >> additive-expression
The operands shall be of integral or unscoped enumeration type and integral promotions are performed. The type of the result is that of the promoted left operand. The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.
2 The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1 × 2^E2, reduced modulo one more than the maximum value representable in the result type. Otherwise, if E1 has a signed type and non-negative value, and E1 × 2^E2 is representable in the corresponding unsigned type of the result type, then that value, converted to the result type, is the resulting value; otherwise, the behavior is undefined.
3 The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

The biggest trap with bit-shifting is to shift e.g. a 32-bit integer by 32.