4 ms·

How about allowing pointers to be compared against NULL after they have been passed to free(): "free(x); if( x!=NULL ){...}" That was completely harmless (and

by SQLite 10y ago

How about allowing pointers to be compared against NULL after they have been passed to free(): "free(x); if( x!=NULL ){...}" That was completely harmless (and a useful idiom) for 45 years, and now suddenly it is flagged as UB and has to be changed. Why? Wouldn't it be great if "memset(0,p,0)" was a harmless no-op? It was for time out of mind. But no more. For bonus points: Can we have a #pragma that tells the compiler to abort with an error if the target machine uses any representation for signed integers other than twos-complement?

dsfuoi 10y ago
Why? Because programmers learned that it is correct, even though it wasn't.(Or at least it stopped being, in C99 an on.) Here is a car analogy. It is like learning to drive and thinking that you are allowed to drive over a yellow-turning-to-red light. However the rules say, you should stop if you are physically able to. In reality almost everyone tries to get over than yellow. On a rare occasion they get spotted and pay the fine. C strives for maximum performance, it will not check things for you if you don't ask it to. Having a library function that performs those checks for everyone, would go against that rule. Why would someone else have to pay the performance penalty for you? Write a wrapper or a macro that performs the check, couple of lines, it is that easy. If you strive to write portable C code it should work regardless of signed representation. C defines all the range macros for types, and gives you types that guarantee certain ranges. Assuming you use those types and macros, I'm really curious what incantations, that couldn't been solved in a portable manner, require you to know the signed representation.
Kristine1975 10y ago
>Can we have a #pragma that tells the compiler to abort with an error if the target machine uses any representation for signed integers other than twos-complement? This should do it (off the cuff): typedef int NOT_TWOS_COMPLEMENT[(unsigned int) -1 == UINT_MAX ? 1 : -1]; In C++ use static_assert.
- dsfuoi 10y ago
  I don't see how that would work. Casting -1 to an unsigned type is independent of representation and will always give the max unsigned value. C has _Static_assert.

by SQLite 10y ago

dsfuoi 10y ago

Why? Because programmers learned that it is correct, even though it wasn't.(Or at least it stopped being, in C99 an on.) Here is a car analogy. It is like learning to drive and thinking that you are allowed to drive over a yellow-turning-to-red light. However the rules say, you should stop if you are physically able to. In reality almost everyone tries to get over than yellow. On a rare occasion they get spotted and pay the fine. C strives for maximum performance, it will not check things for you if you don't ask it to. Having a library function that performs those checks for everyone, would go against that rule. Why would someone else have to pay the performance penalty for you? Write a wrapper or a macro that performs the check, couple of lines, it is that easy. If you strive to write portable C code it should work regardless of signed representation. C defines all the range macros for types, and gives you types that guarantee certain ranges. Assuming you use those types and macros, I'm really curious what incantations, that couldn't been solved in a portable manner, require you to know the signed representation.

Kristine1975 10y ago

>Can we have a #pragma that tells the compiler to abort with an error if the target machine uses any representation for signed integers other than twos-complement? This should do it (off the cuff): typedef int NOT_TWOS_COMPLEMENT[(unsigned int) -1 == UINT_MAX ? 1 : -1]; In C++ use static_assert.

dsfuoi 10y ago
I don't see how that would work. Casting -1 to an unsigned type is independent of representation and will always give the max unsigned value. C has _Static_assert.