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 _______________________________________________ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
