"Might be undefined" Behaviour

[Frederick Gotham]

Eric Sosman:

I once spent
time chasing a bug whose root cause was (paraphrased)

unsigned long x = -1u;

... as a shorthand for "Fill `x' with 1-bits."

Just to make sure I understand here... What that line does is equivalent
to:

unsigned const one_unsigned = 1;

long unsigned x = -one_unsigned;

In order to compute "-one_unsigned", we must traipse over to omnipotent
maths world. In omnipotent maths world, we calculate that the negative of 1
is -1. We then try to store -1 in an unsigned int. Therefore, we can expand
the code to:

unsigned const one_unsigned = 1;

unsigned const negative_of_one_unsigned = -one_unsigned;

long unsigned x = negative_of_one_unsigned;

And of course, this is equal to:

long unsigned x = UINT_MAX;


What the person _should_ have written is:

long unsigned x = ULONG_MAX;

or:

long unsigned x = -1;

Or, if the objective was to set all bits (including padding bits) to 1:

long unsigned x;
memset(&x,UCHAR_MAX,sizeof x);

Anyhow... this just goes to show how I'd never have a use for negating an
unsigned integer.

 

[Eric Sosman]

Frederick Gotham wrote On 11/22/06 16:30,:

Eric Sosman:





Just to make sure I understand here... What that line does is equivalent
to:

unsigned const one_unsigned = 1;

long unsigned x = -one_unsigned;

Yes. It's also equivalent to

unsigned int y = -1; /* an int's worth of 1-bits */
unsigned long x = y; /* 0's (maybe) and 1's */

An interesting observation on the original bug is that it
has two different one-character fixes, an insertion or a
deletion:

unsigned long x = -1uL; /* fix by inserting L */
unsigned long x = -1; /* fix by deleting u */

 

[websnarf]

Schrödinger C?

Potentially undefined behaviour?

But undefined behaviour itself means potentially random behaviour. So
you mean potentially potentially random behaviour?

"Not portable" seems to be quite common.

But that's a description for practically the whole language.

More accurate would be "not portably defined". Or if one is targetting
"C" (i.e., all C platforms simultaneously) then it should just be
called "undefined behaviour".

 

[Old Wolf]

Or, if the objective was to set all bits (including padding bits) to 1:

long unsigned x;
memset(&x,UCHAR_MAX,sizeof x);

Can unsigned integers have padding bits?

 

[CBFalconer]

Can unsigned integers have padding bits?

Yes

 

[Keith Thompson]

Can unsigned integers have padding bits?

Yes (but unsigned char can't).

 

[pete]

Frederick Gotham wrote:

(By the way, I don't see why we're talking about "strictly conforming
programs".)

Neither do I.
"Correct program" is the topic suggested
by the subject line of this thread: Re: "Might be undefined" Behaviour.

If the worst that you can say about a program's output
in terms of behavior,
is that is it contains "unspecified behavior"
then you have a "correct program".

(32767 + 1) is undefined because there is no limit
imposed by the standard on the consequences
of the evaluation of that expression.