Re: Promoting unsigned long int to long int

[Keith Thompson]

pereges <Br*****@gmail.comwrites:
[...]

#define ulong unsigned long int
#define uchar unsigned char

[...]

These types already have perfectly good names already. Why give them
new ones?

If you must rename them for some reason, use typedefs, not macros.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[vippstar]

On Jul 14, 7:14 am, David Thompson <[e-mail]:
<snip>

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)

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 14 Jul 2008 11:16:16 -0700, vippstar wrote:

On Jul 14, 7:14 am, David Thompson <[e-mail]:
<snip>

>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.

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, [...]

[vippstar]

On Jul 14, 11:07 pm, Harald van D©¦k <[e-mail]:

On Mon, 14 Jul 2008 11:16:16 -0700, vippstar wrote:

On Jul 14, 7:14 am, David Thompson <[e-mail]:
<snip>

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. :-)

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 15 Jul 2008 03:40:12 -0700, vippstar wrote:

On Jul 14, 11:07 pm, Harald van Dijk <[e-mail]:

>On Mon, 14 Jul 2008 11:16:16 -0700, vippstar wrote:

On Jul 14, 7:14 am, David Thompson <[e-mail]>
wrote: <snip>
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

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.

[vippstar]

On Jul 15, 4:49 pm, Harald van D©¦k <[e-mail]:
<snip explanation>
Thanks. I have a better understanding now.

[David Thompson]

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