459,405 Members | 1,357 Online
Need help? Post your question and get tips & solutions from a community of 459,405 IT Pros & Developers. It's quick & easy.

Re: Promoting unsigned long int to long int

 P: n/a pereges Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" Jun 30 '08
105 Replies

 P: n/a On Jul 14, 7:14 am, David Thompson Conversion to a signed integer type of an integer value out of range is implementation-defined, and in C99 (explicitly) may raise a signal. On _most_ implementations, for a signed/unsigned pair of types, half the range of the unsigned type is out of range for the signed type. It's undefined behavior, not implementation defined. Also, it's perfectly valid if INT_MAX UINT_MAX (though not INT_MAX > LONG_MAX or INT_MAX ULONG_MAX) Jul 14 '08 #101

 P: n/a On Mon, 14 Jul 2008 11:16:16 -0700, vippstar wrote: On Jul 14, 7:14 am, David Thompson >Conversion to a signed integer type of an integer value out of range isimplementation-defined, and in C99 (explicitly) may raise a signal. On_most_ implementations, for a signed/unsigned pair of types, half therange of the unsigned type is out of range for the signed type. It's undefined behavior, not implementation defined. It's implementation-defined, not undefined. 6.3.1.3 Signed and unsigned integers 1 When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged. 2 Otherwise, if the new type is unsigned, [...] 3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation- defined signal is raised. Also, it's perfectly valid if INT_MAX UINT_MAX (though not INT_MAX LONG_MAX or INT_MAX ULONG_MAX) No, this is not valid. 6.2.5 Types 9 The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, [...] Jul 14 '08 #102

 P: n/a On Jul 14, 11:07 pm, Harald van D©¦k Conversion to a signed integer type of an integer value out of range is implementation-defined, and in C99 (explicitly) may raise a signal. On _most_ implementations, for a signed/unsigned pair of types, half the range of the unsigned type is out of range for the signed type. It's undefined behavior, not implementation defined. It's implementation-defined, not undefined. 6.3.1.3 Signed and unsigned integers 1 When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged. 2 Otherwise, if the new type is unsigned, [...] 3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation- defined signal is raised. Weird, in a recent discussion I've been told that %d in scanf invokes undefined behavior because of overflow. I thought it's the same, for example scanf("%d", &i); input: INT_MAX + 1 i = INT_MAX + 1; /* overflow, undefined behavior OR conversion & implementation-defined? */ Also, it's perfectly valid if INT_MAX UINT_MAX (though not INT_MAX LONG_MAX or INT_MAX ULONG_MAX) No, this is not valid. 6.2.5 Types 9 The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, [...] Ah, thanks. :-) Jul 15 '08 #103

 P: n/a On Tue, 15 Jul 2008 03:40:12 -0700, vippstar wrote: On Jul 14, 11:07 pm, Harald van DÄ³k On Mon, 14 Jul 2008 11:16:16 -0700, vippstar wrote: On Jul 14, 7:14 am, David Thompson wrote: Conversion to a signed integer type of an integer value out of rangeis implementation-defined, and in C99 (explicitly) may raise asignal. On _most_ implementations, for a signed/unsigned pair oftypes, half the range of the unsigned type is out of range for thesigned type. It's undefined behavior, not implementation defined. It's implementation-defined, not undefined.6.3.1.3 Signed and unsigned integers1 When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.2 Otherwise, if the new type is unsigned, [...]3 Otherwise, the new type is signed and the value cannot be represented in > it; either the result is implementation-defined or an implementation- defined signal is raised. Weird, in a recent discussion I've been told that %d in scanf invokes undefined behavior because of overflow. I thought it's the same, for example scanf("%d", &i); input: INT_MAX + 1 There is no relevant conversion here; the behaviour is undefined because the specification of scanf says the behaviour is undefined. The specification of scanf refers to "the result of the conversion", but "conversion" is the plain English word here, and has nothing to do with the type conversions -- those conversions that could be made explicit by a cast. i = INT_MAX + 1; /* overflow, undefined behavior OR conversion & implementation-defined? */ Overflow. If INT_MAX + 1 is evaluated, the behaviour is undefined, and you don't even have to store it in an object for that. If you had used i = INT_MAX + 1u; the addition itself would have defined behaviour. If the result is not within the range of i, and i is signed, then 6.3.1.3p3 applies. Jul 15 '08 #104

 P: n/a On Jul 15, 4:49 pm, Harald van D©¦k Thanks. I have a better understanding now. Jul 15 '08 #105

 P: n/a On Mon, 14 Jul 2008 04:14:03 GMT, I wrote: Aargh! I thought I proofread this. If you really want to accept a _signed_ (possibly but not necessarily negative) number, strol (or ll or max) is usually the right way. If strtol you verify that the value is nonnegative, you can then (guaranteed) convert it to the corresponding signed type without loss of unsigned ! information. If negative, or in a larger/higher-rank type and (actually) out of range, you can still convert to unsigned _safely_, without any impl-def or undefined behavior, but with loss of info. Sorry. - formerly david.thompson1 || achar(64) || worldnet.att.net Jul 28 '08 #106

105 Replies