bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Followup to GNATS gnu/180


From: Duncan Coutts
Subject: Followup to GNATS gnu/180
Date: Tue, 24 Jul 2001 12:31:40 -0500

I realised that the behaviour I reported is undefined by the C language
ie ((int)1 << 63) where int is only 32bit.

As such, the machine can give any result and gdb can give any result. The
two need not be the same. So while the difference may be suprising to a
user, it is allowed.

However, it raises the question of why this code is being used within gdb.
On the platform I am working on, int is 32bit and long is 64bit.

get_discrete_bounds executes the code:
*lowp = -(1 << 63);

where lowp is of type *long.
So it shifts an integer (1) by a large amount, negates it and *then*
promotes it to a long.

This is undefined behaviour according to K&R (pg 189):
"The result is undefined if the right operand is negative, or greater
than or equal to the length of the object in bits"

Relying on this undefined behaviour does indeed give unexpected results on
this platform. The purpose of the get_discrete_bounds function is to get
the least and greatest values that will fit into the given type.
On this platform, lowp comes out as 0 for
get_discrete_bounds(builtin_long), because 1<<63 == 0.
Since the size of long is 8 (builtin_long->length is 8)

*lowp = -(1 << (TYPE_LENGTH (type) * TARGET_CHAR_BIT - 1));

is equivalent to

*lowp = -(1 << 63)

This little bit of code needs to be rethougt to be more portable.
Perhaps 1 ought to be cast to typeof(*lowp) [== LONGEST]

Hope this helps!

Duncan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]