(unsigned)-INT_MIN

[viza]

Hi all

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

Why it might not: -i has type (int), and -INT_MIN might be more than
INT_MAX.

A cast might not work either, because in (unsigned)-i; the cast is too
late, and in -(unsigned)i then i cannot be represented as unsigned.

If long is longer than int, I can do -(long)i, but what if we are talking
about the longest integer type available?

TIA
viza

[vippstar]

On Jul 21, 11:53 am, viza <[e-mail]>
wrote:

Hi all

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

Why it might not: -i has type (int), and -INT_MIN might be more than
INT_MAX.

So what? corresponding integer types have the same range of values; If
int has N values, unsigned int has N values.
It is guaranteed.
<snip>

[rahul]

On Jul 21, 1:53*pm, viza <[e-mail]>
wrote:

Hi all

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

On my system, u becomes 0 as INT_MIN is -2147483648 and INT_MAX is
2147483647. So, -INT_MIN wraps around to 0.

Why it might not: -i has type (int), and -INT_MIN might be more than
INT_MAX.

-INT_MIN is greater than INT_MAX on most of the systems.

If long is longer than int, I can do -(long)i, but what if we are talking
about the longest integer type available?

What are we looking at? Is it about getting the absolute value of a
signed int in an unsigned int?

[vippstar]

On Jul 21, 12:21 pm, [e-mail] wrote:

On Jul 21, 11:53 am, viza <[e-mail]>
wrote:Hi all

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

Why it might not: -i has type (int), and -INT_MIN might be more than
INT_MAX.

So what? corresponding integer types have the same range of values; If
int has N values, unsigned int has N values.
It is guaranteed.
<snip>

I'm sorry, I misunderstood you. You're interested in the case that
INT_MIN < -INT_MAX.
Well, in that case, computing -INT_MIN invokes undefined behavior;
(overflow)
Try this

if(i == INT_MIN)
u += INT_MAX + (unsigned)-(i + INT_MAX);
u = -i;

[Old Wolf]

On Jul 21, 8:53 pm, viza <[e-mail]>
wrote:

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

No. On a normal (2's complement) system, the
code causes undefined behaviour because the
operation "-i" causes an integer overflow.

Not sure what 'vipps' was on about..

A cast might not work either, because in (unsigned)-i; the cast is too
late, and in -(unsigned)i then i cannot be represented as unsigned.

Signed values can be converted to unsigned ;
(unsigned)i is guaranteed to be UINT_MAX - INT_MIN,
which is INT_MAX on the normal machine.

[vippstar]

On Jul 21, 12:38 pm, Old Wolf <[e-mail]:

On Jul 21, 8:53 pm, viza <[e-mail]>
wrote:

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

No. On a normal (2's complement) system, the
code causes undefined behaviour because the
operation "-i" causes an integer overflow.

Not sure what 'vipps' was on about..

Which one of my two (without counting this one) messages are you
refering to?
I posted a follow-up quoting my first message saying I misunderstood,
and then I gave an answer which I believe to be correct. (and
relevant)

A cast might not work either, because in (unsigned)-i; the cast is too
late, and in -(unsigned)i then i cannot be represented as unsigned.

Signed values can be converted to unsigned ;
(unsigned)i is guaranteed to be UINT_MAX - INT_MIN,
which is INT_MAX on the normal machine.

Wrong.
Assuming i is -N with N >= 0, (unsigned)i is UINT_MAX - N + 1.
So (unsigned)INT_MIN would be UINT_MAX + INT_MIN + 1.

[vippstar]

On Jul 21, 12:36 pm, [e-mail] wrote:
<snip>

Try this

if(i == INT_MIN)
u += INT_MAX + (unsigned)-(i + INT_MAX);
u = -i;

^
insert 'else' there... :-( I should be looking twice at my messages
before posting them.

[viza]

Hi

On Mon, 21 Jul 2008 08:53:51 +0000, viza wrote:

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

If long is longer than int, I can do -(long)i, but what if we are
talking about the longest integer type available?

Thanks for the answers so far, but none of them help. Perhaps I can
explain it a bit better:

What I would like is a constant expression of unsigned type for the
absolute value of an constant negative expression of the corresponding
signed type.

Ie:

1) I know i is negative
2) I want (unsigned)abs(i)

The answer simply: ( (unsigned)-i ) for any i except INT_MIN. What is
the answer for INT_MIN? or for any i?

Thanks,

viza

[viza]

Hi

On Mon, 21 Jul 2008 10:02:32 +0000, viza wrote:

What I would like is a constant expression of unsigned type for the
absolute value of an constant negative expression of the corresponding
signed type.

Thanks for the answers so far, but none of them help

I could use a conditional operation based on vippstars second post, but
is there a neater way?

viza

[Old Wolf]

On Jul 21, 9:51 pm, [e-mail] wrote:

On Jul 21, 12:38 pm, Old Wolf <[e-mail]:

Not sure what 'vipps' was on about..

Which one of my two (without counting this one) messages are you
refering to?

I was referring to your first post on this thread
(and I posted before you posted your correction).

Signed values can be converted to unsigned ;
(unsigned)i is guaranteed to be UINT_MAX - INT_MIN,
which is INT_MAX on the normal machine.

Wrong.
Assuming i is -N with N >= 0, (unsigned)i is UINT_MAX - N + 1.
So (unsigned)INT_MIN would be UINT_MAX + INT_MIN + 1.

Knew I should have checked that more before
posting .. the baby was crying though :)

[Old Wolf]

On Jul 21, 10:02 pm, viza <[e-mail]>
wrote:

What I would like is a constant expression of unsigned type for the
absolute value of an constant negative expression of the corresponding
signed type.

-(unsigned)i

Assuming i is negative, then:
(unsigned)i is UINT_MAX + 1 - abs(i)
so the negative of that is
UINT_MAX + 1 - (UINT_MAX + 1 - abs(i))
which is abs(i).

[pete]

viza wrote:

Hi

On Mon, 21 Jul 2008 08:53:51 +0000, viza wrote:

>int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

>If long is longer than int, I can do -(long)i, but what if we are
talking about the longest integer type available?

Thanks for the answers so far, but none of them help. Perhaps I can
explain it a bit better:

What I would like is a constant expression of unsigned type for the
absolute value of an constant negative expression of the corresponding
signed type.

Ie:

1) I know i is negative
2) I want (unsigned)abs(i)

The answer simply: ( (unsigned)-i ) for any i except INT_MIN. What is
the answer for INT_MIN? or for any i?

There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

--
pete

[vippstar]

On Jul 21, 5:56 pm, pete <[e-mail]:
<snip>

There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

That's incorrect. Do you mean no signed integer type? If so, that is
correct.
unsigned int, unsigned long int, unsigned long long int, all can
represent the absolute value of INT_MIN.

[Keith Thompson]

vi******@gmail.com writes:

On Jul 21, 5:56 pm, pete <[e-mail]:
<snip>

>There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

That's incorrect. Do you mean no signed integer type? If so, that is
correct.
unsigned int, unsigned long int, unsigned long long int, all can
represent the absolute value of INT_MIN.

That's true on most systems, but it's not guaranteed by the standard.

A conforming system could have padding bits in unsigned int, so that
UINT_MAX == INT_MAX. And unsigned long int and unsigned long long int
could both have the same size and representation as unsigned int
(assuming UINT_MAX >= 2**64-1).

Such a system is unlikely to exist in real life. int and unsigned int
would have to be at least 65 bits (33 bits if you'll settle for C90
conformance).

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

[pete]

vi******@gmail.com wrote:

On Jul 21, 5:56 pm, pete <[e-mail]:
<snip>

>There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

That's incorrect. Do you mean no signed integer type? If so, that is
correct.
unsigned int, unsigned long int, unsigned long long int, all can
represent the absolute value of INT_MIN.

No.
ULONG_MAX can be 4294967295
while INT_MIN can be (-4294967296)
on the same implementation.

--
pete

[lawrence.jones]

viza <to******@gm-il.com.obviouschange.invalidwrote:

>
int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

No, for the reason you give:

Why it might not: -i has type (int), and -INT_MIN might be more than
INT_MAX.

A cast might not work either, because in (unsigned)-i; the cast is too
late,

Correct.

and in -(unsigned)i then i cannot be represented as unsigned.

No, i can always be represented as unsigned because conversion to
unsigned is done modulo (UINT_MAX + 1). Since unsigned negation is
equivalent to subtracting the value from (UINT_MAX + 1), -(unsigned)i
produces the value (UINT_MAX + 1) - (UINT_MAX + 1 + i), which is -i and
exactly what you want, provided -INT_MAX is actually representable as an
unsigned. Although that is almost certainly true in practice, it is not
guaranteed by the standard.
--
Larry Jones

I can feel my brain beginning to atrophy already. -- Calvin

[viza]

Hi all

int i= INT_MIN;
unsigned int u= -i;

Is u guaranteed to have the absolute value of INT_MIN?

I've solved it:

int i= INT_MIN;
unsigned int u= 0U-(unsigned)i;

For any negative valued expression i of signed integer type t

( 0U - (unsigned t) i )

is an expression with compatible unsigned type having the absolute value
of i. No signed intermediates are used so it works even with INT_MIN on
a twos compliment implementation.

This has taken too long for something so trivial. IMHO it's stupid that
abs() has signed return type. All I really needed was a function like:

unsigned int uabs( int i ){
return (0<i) ? ((unsigned int)i) : (0U-(unsigned int)i);
}

[viza]

On Mon, 21 Jul 2008 22:18:58 +0000, viza wrote:

For any negative valued expression i of signed integer type t

( 0U - (unsigned t) i )

is an expression with compatible unsigned type having the absolute value
of i.

....if one exists.

[Peter Nilsson]

viza wrote:

I've solved it:

No you haven't.

int i= INT_MIN;
unsigned int u= 0U-(unsigned)i;

The cast is redundant in context.

unsigned u = 0u - i; /* or... */
unsigned u = - (unsigned) INT_MIN;

For any negative valued expression i of signed integer type t

( 0U - (unsigned t) i )

Except INT_MIN on an implementation where UINT_MAX == INT_MAX.

is an expression with compatible unsigned type having the absolute value
of i. No signed intermediates are used so it works even with INT_MIN on
a twos compliment implementation.

With 1 exception.

This has taken too long for something so trivial. IMHO it's stupid that
abs() has signed return type.

Well it's easy to criticise with 40 years of hindsight.

All I really needed was a function like:

unsigned int uabs( int i ){
return (0<i) ? ((unsigned int)i) : (0U-(unsigned int)i);
}

Or you may be able to modify your algorithm to not care about the
absolute value. That would be the better course. In fact, it often
leads to efficiencies.

--
Peter

[vippstar]

On Jul 21, 7:58 pm, Keith Thompson <[e-mail]:

[e-mail] writes:

On Jul 21, 5:56 pm, pete <[e-mail]:
<snip>

There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

That's incorrect. Do you mean no signed integer type? If so, that is
correct.
unsigned int, unsigned long int, unsigned long long int, all can
represent the absolute value of INT_MIN.

That's true on most systems, but it's not guaranteed by the standard.

A conforming system could have padding bits in unsigned int, so that
UINT_MAX == INT_MAX. And unsigned long int and unsigned long long int
could both have the same size and representation as unsigned int
(assuming UINT_MAX >= 2**64-1).

Such a system is unlikely to exist in real life. int and unsigned int
would have to be at least 65 bits (33 bits if you'll settle for C90
conformance).

I thought that corresponding integer types have both N range values?

[Keith Thompson]

vi******@gmail.com writes:

On Jul 21, 7:58 pm, Keith Thompson <[e-mail]:

>[e-mail] writes:

On Jul 21, 5:56 pm, pete <[e-mail]:
<snip>
There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

That's incorrect. Do you mean no signed integer type? If so, that is
correct.
unsigned int, unsigned long int, unsigned long long int, all can
represent the absolute value of INT_MIN.

That's true on most systems, but it's not guaranteed by the standard.

A conforming system could have padding bits in unsigned int, so that
UINT_MAX == INT_MAX. And unsigned long int and unsigned long long int
could both have the same size and representation as unsigned int
(assuming UINT_MAX >= 2**64-1).

Such a system is unlikely to exist in real life. int and unsigned int
would have to be at least 65 bits (33 bits if you'll settle for C90
conformance).

I thought that corresponding integer types have both N range values?

No, that's not required (if I understand you correctly). Both signed
int and unsigned int are allowed to have padding bits; there's no
requirement that they have the same number of padding bits.

An implementation where:

int and unsigned int are both 32 bits;

int has 31 value bits and 1 sign bit, with a range of
-2147483648 .. 2147483647;

unsigned int has 31 value bits and 1 padding bit, with a range
of 0 .. 2147483647

could be conforming. It would even be sensible on an implementation
where the hardware doesn't support unsigned arithmetic, or where
signed and unsigned integers are represented as floating-point with a
fixed exponent.

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

[Robbie Hatley]

"pete" wrote:

There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

True. However, on most 32-bit platforms, if "long long int"
(the new C99 type) is defined at all, it is usually larger
than either int or long. It's typically 8 bytes wide and
able to represent numbers from (roughly) -9.2E18 to +9.2E18.

So, if your compiler supports "long long int", look in
file "limits.h" and see what limits it gives. If
LLONG_MIN < INT_MIN and LLONG_MAX INT_MAX
(and they usually are), then the new "long long int" type
CAN represent abs(INT_MIN) on your platform & compiler.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Greg Comeau]

In article <Jo******************************@giganews.com>,
Robbie Hatley <se**************@for.my.email.addresswrote:

>
"pete" wrote:

>There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

True. However, on most 32-bit platforms, if "long long int"
(the new C99 type) is defined at all, it is usually larger
than either int or long. It's typically 8 bytes wide and
able to represent numbers from (roughly) -9.2E18 to +9.2E18.

So, if your compiler supports "long long int", look in
file "limits.h" and see what limits it gives. If
LLONG_MIN < INT_MIN and LLONG_MAX INT_MAX
(and they usually are), then the new "long long int" type
CAN represent abs(INT_MIN) on your platform & compiler.

No matter if this is the case or not, pete wrote about guarantees,
whereas you're writing about if's and can's.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[pete]

vi******@gmail.com wrote:

On Jul 21, 7:58 pm, Keith Thompson <[e-mail]:

>[e-mail] writes:

>>On Jul 21, 5:56 pm, pete <[e-mail]:
<snip>
There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

I thought that corresponding integer types have both N range values?

INT_MAX is allowed to be as high as UINT_MAX.

--
pete

[vippstar]

On Jul 22, 2:38 am, Keith Thompson <[e-mail]:

[e-mail] writes:

<snip>

I thought that corresponding integer types have both N range values?

No, that's not required (if I understand you correctly). Both signed
int and unsigned int are allowed to have padding bits; there's no
requirement that they have the same number of padding bits.

An implementation where:

<snip>

Again, I misunderstood a reply from a previous thread.
Thanks.

[Old Wolf]

On Jul 22, 10:18 am, viza <[e-mail]>
wrote:

>
I've solved it:

int i= INT_MIN;
unsigned int u= 0U-(unsigned)i;

This has taken too long for something so trivial.

I posted this solution 18 hours ago..

(note that the "0U" makes no difference)

[viza]

On Tue, 22 Jul 2008 02:49:02 -0700, Old Wolf wrote:

On Jul 22, 10:18 am, viza wrote:

>>
unsigned int u= 0U-(unsigned)i;

This has taken too long for something so trivial.

I posted this solution 18 hours ago..

(note that the "0U" makes no difference)

Yes, but a brain deficit on my part convinced me that the result of unary
negation was signed. :-S

[Robbie Hatley]

"Greg Comeau" wrote:

Robbie Hatley wrote:

"pete" wrote:

There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

True. However, on most 32-bit platforms, if "long long int"
(the new C99 type) is defined at all, it is usually larger
than either int or long. It's typically 8 bytes wide and
able to represent numbers from (roughly) -9.2E18 to +9.2E18.

So, if your compiler supports "long long int", look in
file "limits.h" and see what limits it gives. If
LLONG_MIN < INT_MIN and LLONG_MAX INT_MAX
(and they usually are), then the new "long long int" type
CAN represent abs(INT_MIN) on your platform & compiler.

No matter if this is the case or not, pete wrote about guarantees,
whereas you're writing about if's and can's.

Life's not fair. There are never any guarantees of anything,
even if some standard says there are. Live with it.

Example: In C, the latest standard mandates that all compilers
provide data type "long long int". BUT, some compilers don't.
Oh well.

Example: In C++, the latest standard mandates that all compilers
impliment keyword "export" (for exporting templates). But many
(most?) C++ compilers don't. Oh well.

But I think most C and C++ compilers DO have type "long long int",
and I believe that in *ALL* which do, this type has much greater
bit width than type "int".

If you think this is not so, then tell me of a compiler where:

char = 1 bytes
short = 2 bytes
int = 4 bytes
long = 4 bytes
long long = 4 bytes

I doubt anyone is going to bother implimenting "long long" only
to make it the same as "int".

CVI (from National Instruments):

char = 1 bytes
short = 2 bytes
int = 4 bytes
long = 4 bytes
long long = 8 bytes

DJGPP (DJ Delorie's port of g++ to win32 cmd prompt):

char = 1 bytes
short = 2 bytes
int = 4 bytes
long = 4 bytes
long long = 8 bytes

I tell you what... I'll mail $2 in cash to the first person
who can demonstrate to me a popular C compiler which impliments
"int", "long", and "long long" as all being the same bit width.
I think you can call that a "money back guarantee". :-)

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Greg Comeau]

In article <dO******************************@giganews.com>,
Robbie Hatley <se**************@for.my.email.addresswrote:

>"Greg Comeau" wrote:

>Robbie Hatley wrote:

>"pete" wrote:
There is no integer type which is guaranteed
to be able to represent the absolute value of INT_MIN.

True. However, on most 32-bit platforms, if "long long int"
(the new C99 type) is defined at all, it is usually larger
than either int or long. It's typically 8 bytes wide and
able to represent numbers from (roughly) -9.2E18 to +9.2E18.

So, if your compiler supports "long long int", look in
file "limits.h" and see what limits it gives. If
LLONG_MIN < INT_MIN and LLONG_MAX INT_MAX
(and they usually are), then the new "long long int" type
CAN represent abs(INT_MIN) on your platform & compiler.

No matter if this is the case or not, pete wrote about guarantees,
whereas you're writing about if's and can's.

Life's not fair. There are never any guarantees of anything,
even if some standard says there are. Live with it.

Example: In C, the latest standard mandates that all compilers
provide data type "long long int". BUT, some compilers don't.
Oh well.

Good point. However, it doesn't negate what I said.

>Example: In C++, the latest standard mandates that all compilers
impliment keyword "export" (for exporting templates). But many
(most?) C++ compilers don't. Oh well.

Well, I know one which does. :) Ok, ok, let's move on :)

>But I think most C and C++ compilers DO have type "long long int",
and I believe that in *ALL* which do, this type has much greater
bit width than type "int".

If you think this is not so, then tell me of a compiler where:

char = 1 bytes
short = 2 bytes
int = 4 bytes
long = 4 bytes
long long = 4 bytes

I doubt anyone is going to bother implimenting "long long" only
to make it the same as "int".

Again, I don't think this has to do with the comment I made, but
so long as you raise it: We've (Comeau C/C++) has done so on a number
of occassions, similarly for double and long double. I seem
to recall a few where all types were the same size, though I'd
probably not want to remember which those were. :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Keith Thompson]

"Robbie Hatley" <se**************@for.my.email.addresswrites:
[...]

Life's not fair. There are never any guarantees of anything,
even if some standard says there are. Live with it.

Example: In C, the latest standard mandates that all compilers
provide data type "long long int". BUT, some compilers don't.
Oh well.

All compilers that conform to the C99 standard provide long long int.
That's not a guarantee; it's a tautology Any compiler that doesn't
provide long long int does not conform to the C99 standard.

No standard can mandate the behavior of implementations that don't
conform to it.

Example: In C++, the latest standard mandates that all compilers
impliment keyword "export" (for exporting templates). But many
(most?) C++ compilers don't. Oh well.

But I think most C and C++ compilers DO have type "long long int",
and I believe that in *ALL* which do, this type has much greater
bit width than type "int".

The C++ doesn't (yet) define long long int, unless I've missed a new
version. But C++ is off-topic here -- and the point is made equally
well just by referring to C.

If you think this is not so, then tell me of a compiler where:

char = 1 bytes
short = 2 bytes
int = 4 bytes
long = 4 bytes
long long = 4 bytes

I doubt anyone is going to bother implimenting "long long" only
to make it the same as "int".

Such an implementation is non-conforming unless CHAR_BIT >= 16.
The standard requires a minimum range for type long long; that
range cannot be satisified unless it's at least 64 bits.

[...]

I tell you what... I'll mail $2 in cash to the first person
who can demonstrate to me a popular C compiler which impliments
"int", "long", and "long long" as all being the same bit width.
I think you can call that a "money back guarantee". :-)

I have a C program that prints the characteristics of several C types,
and I've saved the output from the Cray C90, T90, T3E, and SV1. On
all those systems, types int, long, and long long are all 64 bits.
(None of those systems had a C99 compiler, but apparently they all
provided long long as an extension.)

I'm not going to claim your $2, since I wouldn't describe any of those
systems as "popular".

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

[Greg Comeau]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>"Robbie Hatley" <se**************@for.my.email.addresswrites:
[...]

>Life's not fair. There are never any guarantees of anything,
even if some standard says there are. Live with it.

Example: In C, the latest standard mandates that all compilers
provide data type "long long int". BUT, some compilers don't.
Oh well.

All compilers that conform to the C99 standard provide long long int.
That's not a guarantee; it's a tautology Any compiler that doesn't
provide long long int does not conform to the C99 standard.

No standard can mandate the behavior of implementations that don't
conform to it.

>Example: In C++, the latest standard mandates that all compilers
impliment keyword "export" (for exporting templates). But many
(most?) C++ compilers don't. Oh well.

But I think most C and C++ compilers DO have type "long long int",
and I believe that in *ALL* which do, this type has much greater
bit width than type "int".

The C++ doesn't (yet) define long long int, unless I've missed a new
version. But C++ is off-topic here -- and the point is made equally
well just by referring to C.

>If you think this is not so, then tell me of a compiler where:

char = 1 bytes
short = 2 bytes
int = 4 bytes
long = 4 bytes
long long = 4 bytes

I doubt anyone is going to bother implimenting "long long" only
to make it the same as "int".

Such an implementation is non-conforming unless CHAR_BIT >= 16.
The standard requires a minimum range for type long long; that
range cannot be satisified unless it's at least 64 bits.

[...]

>I tell you what... I'll mail $2 in cash to the first person
who can demonstrate to me a popular C compiler which impliments
"int", "long", and "long long" as all being the same bit width.
I think you can call that a "money back guarantee". :-)

I have a C program that prints the characteristics of several C types,
and I've saved the output from the Cray C90, T90, T3E, and SV1. On
all those systems, types int, long, and long long are all 64 bits.
(None of those systems had a C99 compiler, but apparently they all
provided long long as an extension.)

I'm not going to claim your $2, since I wouldn't describe any of those
systems as "popular".

I've been emailed to provide some platforms that I said I'd rather
forget in my post. But honestly, I can't recall exactly which they
were, but if I have to choose it seems to me included some
Amdahl's, at least two different DG machines, and some sort of
embedded chip ADCsomething or AHCsomething. Probably some others too.
Seem to recall some weird void * stuff on those too.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?