How to represent the biggest number in a system

[fdmfdmfdm]

let's say without checking including files, how do we to represent the
biggest say int in a system?

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

Does that mean the long int at that system is only 32 bits? If we know
in a particular system, the long int is 64 bits, shall we write:

long int biggest = 0x7FFFFFFFFFFFFFFF?

By the way, the book is written in 1994.

Thank you.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

fd*******@gmail.com wrote:

let's say without checking including files, how do we to represent the
biggest say int in a system?

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

Does that mean the long int at that system is only 32 bits?

No, it will also work when long int is 64 bits (or any other allowable
number of bits). When long int has more than 32 (non-padding) bits,
you will get exactly 0x7FFFFFFF, not the maximum value. There are more
than enough situations when this is exactly what's intended, and your
post doesn't say enough to clarify whether the code might be used in
such a situation.

If we know
in a particular system, the long int is 64 bits, shall we write:

long int biggest = 0x7FFFFFFFFFFFFFFF?

If you want the maximum value for a long int, include <limits.h>, and
use LONG_MAX.

[fdmfdmfdm]

On Feb 2, 2:35Â*pm, "Harald van Dijk" <[e-mail]:

[e-mail] wrote:

let's say without checking including files, how do we to represent the
biggest say int in a system?

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

Does that mean the long int at that system is only 32 bits?

No, it will also work when long int is 64 bits (or any other allowable
number of bits). When long int has more than 32 (non-padding) bits,
you will get exactly 0x7FFFFFFF, not the maximum value. There are more
than enough situations when this is exactly what's intended, and your
post doesn't say enough to clarify whether the code might be used in
such a situation.

If we know
in a particular system, the long int is 64 bits, shall we write:

long int biggest = 0x7FFFFFFFFFFFFFFF?

If you want the maximum value for a long int, include <limits.h>, and
use LONG_MAX.

To my understanding, F represents 1111, so how come 0x7FFFFFFF will
represent some value more than 32 bits? Please forgive my stupidity
ahead.

[Ian Collins]

fd*******@gmail.com wrote:

On Feb 2, 2:35 pm, "Harald van Dijk" <[e-mail]:

>>[e-mail] wrote:

>>>let's say without checking including files, how do we to represent the
biggest say int in a system?

>>>I ran across a book give this code:

>>>long int biggest = 0x7FFFFFFF;

>>>Does that mean the long int at that system is only 32 bits?

No, it will also work when long int is 64 bits (or any other allowable
number of bits). When long int has more than 32 (non-padding) bits,
you will get exactly 0x7FFFFFFF, not the maximum value. There are more
than enough situations when this is exactly what's intended, and your
post doesn't say enough to clarify whether the code might be used in
such a situation.

>>>If we know
in a particular system, the long int is 64 bits, shall we write:

>>>long int biggest = 0x7FFFFFFFFFFFFFFF?

If you want the maximum value for a long int, include <limits.h>, and
use LONG_MAX.

To my understanding, F represents 1111, so how come 0x7FFFFFFF will
represent some value more than 32 bits? Please forgive my stupidity
ahead.

It doesn't, it represents exactly 0x7FFFFFFF for any type with >= 32
bits. This may, or may not, be the maximum value for the type.

--
Ian Collins.

[fdmfdmfdm]

On Feb 2, 3:07Â*pm, Ian Collins <[e-mail]:

[e-mail] wrote:

On Feb 2, 2:35 pm, "Harald van Dijk" <[e-mail]:

>[e-mail] wrote:

>>let's say without checking including files, how do we to represent the
biggest say int in a system?

>>I ran across a book give this code:

>>long int biggest = 0x7FFFFFFF;

>>Does that mean the long int at that system is only 32 bits?

>No, it will also work when long int is 64 bits (or any other allowable
number of bits). When long int has more than 32 (non-padding) bits,
you will get exactly 0x7FFFFFFF, not the maximum value. There are more
than enough situations when this is exactly what's intended, and your
post doesn't say enough to clarify whether the code might be used in
such a situation.

>>If we know
in a particular system, the long int is 64 bits, shall we write:

>>long int biggest = 0x7FFFFFFFFFFFFFFF?

>If you want the maximum value for a long int, include <limits.h>, and
use LONG_MAX.

To my understanding, F represents 1111, so how come 0x7FFFFFFF will
represent some value more than 32 bits? Please forgive my stupidity
ahead.

It doesn't, it represents exactly 0x7FFFFFFF for any type with >= 32
bits. Â*This Â*may, or may not, be the maximum value for the type.

--
Ian Collins.- Hide quoted text -

- Show quoted text -

So, what you are saying is that 0x7FFFFFFF is actually
01111111111111111111111111111111 total 32 bits, right? In my post, I
assume we are not using anything from limits.h

Thank you.

[Walter Roberson]

In article <11*********************@j27g2000cwj.googlegroups. com>,
fd*******@gmail.com <fd*******@gmail.comwrote:

>To my understanding, F represents 1111, so how come 0x7FFFFFFF will
represent some value more than 32 bits?

If you are assigning 0x7FFFFFFF to a variable that is more than
32 bits, then leading zeros will be used for the remaining bits.
For example, on a system with a 64 bit int,
int foo = 0x7FFFFFFF;
would initialize foo to 0x000000007FFFFFFF .

This is the merely the same practice as assuming leading zeros
for decimal numbers -- e.g., when you write the number 64,
you do not have to write 00000000064 to indicate 0 hundreds,
0 thousands, 0 ten-thousands and so on. [Note: in C, explicitly
giving leading 0s on a constant has a specific meaning, of indicating
that the constant has been written in octal.]
The poster who replied to you saying that,
int biggest = 0x7FFFFFFF;
would work on a system with 64 bit int was correct: it would
create a 64 bit int whose value is 31 consequative binary 1s.

The poster indicated that whether that is what you *wanted* would
depend on the context, and if what you *wanted* was the maximum
positive int available on the implementation, then you should
write something like,
int biggest = INT_MAX;
where INT_MAX is defined in the standard header file limits.h .

What the poster who replied to you implied, but did not say outright,
is that coding
int biggest = 0x7FFFFFFF;
does *not* mean that the variable named 'biggest' will somehow be
assigned the maximum positive int for the implementation: it just
assigns that particular constant value to a storage location whose
human-readable name is 'biggest', and it might -happen- that that
particular constant is the largest positive int for that
implementation. Compilers don't care what human-readable name is used:
exactly the same thing would happen for
int smallest = 0x7FFFFFFF;

--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[Ian Collins]

fd*******@gmail.com wrote:

>>

>>>To my understanding, F represents 1111, so how come 0x7FFFFFFF will
represent some value more than 32 bits? Please forgive my stupidity
ahead.

It doesn't, it represents exactly 0x7FFFFFFF for any type with >= 32
bits. This may, or may not, be the maximum value for the type.

So, what you are saying is that 0x7FFFFFFF is actually
01111111111111111111111111111111 total 32 bits, right? In my post, I
assume we are not using anything from limits.h

I don't see what limits.h has to do the the representation of a number.

If you did want to find the maximum value of an integer type, something
like the following abomination might work for you:

#include <stdio.h>

int main(void)
{
int i = (int)((-1U)>>1);
long l = (long)((-1UL)>>1);

printf("%x %lx\n", i, l);
}

--
Ian Collins.

[Keith Thompson]

"fd*******@gmail.com" <fd*******@gmail.comwrites:

let's say without checking including files, how do we to represent the
biggest say int in a system?

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

Does that mean the long int at that system is only 32 bits?

It means that the author decided to declare a variable of type long
int named "biggest", and to initialize it to 0x7FFFFFFF (which is
equivalent to 2147483647). There is no meaning to that C code beyond
that. If the author meant something more by it, he probably said so
in the surrounding text (or he should have).

If we know
in a particular system, the long int is 64 bits, shall we write:

long int biggest = 0x7FFFFFFFFFFFFFFF?

Sure, you can write that if you like. It's the same as the first
declaration, except that the initial value is 0x7FFFFFFFFFFFFFFF
(9223372036854775807). Such a declaration is non-portable, since that
value might not be representable in the type.

If it was intended to represent the maximum value of type long int,
then it should have been declared as "const". But the correct way to
obtain the largest value of type long int is to include the <limits.h>
header and refer to LONG_MAX. This is guaranteed to give you the
correct value for any implementation; it's the implementation's job to
define it correctly.

How do you get this value *without* including the <limits.hheader?
There may be some way to do it, but why on Earth would you want to?
<limits.hexists for a reason. Just use it.

On the other hand, the largest *portable* value of type long int is
0x7FFFFFFF, and <limits.hdoesn't define anything for this value. So
if you need the largest portable value for some reason, declaring it
yourself is your best option. I'd probably use a macro rather than a
declaration, since even a "const" object isn't "constant" (for
example, it can't be used in a switch statement).

#define PORTABLE_LONG_MAX 0x7FFFFFFFL

(The 'L' suffix guarantees that the constant is of type long int, even
if the value 0x7FFFFFFF happens to fit in an int.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[David T. Ashley]

<fd*******@gmail.comwrote in message
news:11**********************@a34g2000cwb.googlegr oups.com...

let's say without checking including files, how do we to represent the
biggest say int in a system?

And how exactly do you expect to write portable code if you're going to
ignore the system provisions that were designed to facilitate that goal?
You can do it in this case, but not in all cases.

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

Does that mean the long int at that system is only 32 bits? If we know
in a particular system, the long int is 64 bits, shall we write:

long int biggest = 0x7FFFFFFFFFFFFFFF?

First, until relatively recently, 32-bit integers were entrenched, and this
could be assumed on just about every platform. So, a book author using
non-portable code like this can be excused. Second, a book author might do
this for simplicity -- to avoid examples that distract from the concept s/he
is trying to present in that example or chapter.

But, in the general case, this won't fly.

The safest way to deal with this is to use the constants in <limits.h>.

The second-safest way (since just about every platform is 2's complement
these days) is to use some expression that automatically sizes to the native
integer size. Off the top of my head,

((unsigned)-1 >1)

might work.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Ben Pfaff]

"fd*******@gmail.com" <fd*******@gmail.comwrites:

let's say without checking including files, how do we to represent the
biggest say int in a system?

Why not use header files? That's what they're there for.
INT_MAX from <limits.his perfect for the purpose.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

[Keith Thompson]

"David T. Ashley" <dt*@e3ft.comwrites:

<fd*******@gmail.comwrote in message
news:11**********************@a34g2000cwb.googlegr oups.com...

let's say without checking including files, how do we to represent the
biggest say int in a system?

And how exactly do you expect to write portable code if you're going to
ignore the system provisions that were designed to facilitate that goal?
You can do it in this case, but not in all cases.

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

Does that mean the long int at that system is only 32 bits? If we know
in a particular system, the long int is 64 bits, shall we write:

long int biggest = 0x7FFFFFFFFFFFFFFF?

First, until relatively recently, 32-bit integers were entrenched, and this
could be assumed on just about every platform. So, a book author using
non-portable code like this can be excused. Second, a book author might do
this for simplicity -- to avoid examples that distract from the concept s/he
is trying to present in that example or chapter.

[...]

I disagree. A book author, of all people, should know better than to
make undocumented assumptions like this. All the world never was a
VAX, and all the world is not an x86 now.

Without more context than a single questionable declaration, we can't
really say that the author made an unjustified assumption. "biggest"
doesn't *necessarily* mean the biggest value of type long int. But if
that's what it means, then asserting that it's always 2**31-1 is just
wrong.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Peter Nilsson]

"David T. Ashley" <[e-mail]:

<[e-mail]

let's say without checking including files, how do we to represent the
biggest say int in a system?

And how exactly do you expect to write portable code if you're going to
ignore the system provisions that were designed to facilitate that goal?
You can do it in this case, but not in all cases.

I ran across a book give this code:

long int biggest = 0x7FFFFFFF;

<snip>

The safest way to deal with this is to use the constants in <limits.h>.

The second-safest way

[With clear daylight behind the safest way...]

(since just about every platform is 2's complement
these days) is to use some expression that automatically sizes to the
native integer size. Off the top of my head,

((unsigned)-1 >1)

might work.

More simply (-1u >1).

It will work on vanilla machines, but it won't work on death stations.
UINT_MAX == INT_MAX is allowed. UINT_MAX 4 * INT_MAX is
allowed. [UINT_MAX >= INT_MAX is required.]

It is possible to 'compute' the maximum value of int on a C90
implementation... [method from Lawrance Kirby]

int int_max(void)
{
unsigned u = -1;
int i;
while ((i = u) < 0 || i != u) u /= 2;
return i;
}

....but it cannot be done portably as a constant expression.

--
Peter

[David T. Ashley]

"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...

>
It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[David T. Ashley]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"David T. Ashley" <dt*@e3ft.comwrites:

>>
First, until relatively recently, 32-bit integers were entrenched, and
this
could be assumed on just about every platform. So, a book author using
non-portable code like this can be excused. Second, a book author might
do
this for simplicity -- to avoid examples that distract from the concept
s/he
is trying to present in that example or chapter.

[...]

I disagree. A book author, of all people, should know better than to
make undocumented assumptions like this. All the world never was a
VAX, and all the world is not an x86 now.

I disagree with you. It has always been a justifiable tool in teaching to
ignore or abstract to oblivion facts that aren't relevant or would distract
from what one is trying to teach at that moment. Even V=IR isn't strictly
true when you look at it closely enough. But it is close enough for most
applications. (And the current into the inputs of an op-amp is NOT zero.)

Sometimes the complexity of the total thing to be taught is so overwhelming
that this is necessary. Flight training is a good example. Learning to
steer with one's feet is quite hard (if you've not done it before), so for
the first several lessons a flight instructor will handle that (usually,
without indicating it) and let the student concentrate on handling the
vertical aspect of takeoffs and landings (which is hard enough on its own).
It would be almost impossible to teach a person to fly an airplane without
taking away some of the complexity initially.

Integers are always 32 bits and the largest positive integer is always
0x7FFFFFFF. Seems harmless enough to me, and it will work until the student
needs to know otherwise.
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Malcolm McLean]

"David T. Ashley" <dt*@e3ft.comwrote in message

"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...

>>
It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

It is machine invented by a former reg called Kaz Kazsomethingorother - he
had an Arabic surname I never worked out how to pronounce - which implements
a C compiler as perversely as possible, though fully conforming.
So it would use sign magnitude representation instead of two's complement,
for instance.

David Ashley

>

>>More simply (-1u >1).

Would naturally cause a trap representation and program termination.

[David T. Ashley]

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:r8******************************@bt.com...

>
David Ashley

>>

>>>More simply (-1u >1).

Would naturally cause a trap representation and program termination.

I didn't write that.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Keith Thompson]

"David T. Ashley" <dt*@e3ft.comwrites:

"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...

It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

The Deathstation 9000 (DS9K) is a mythical computer system whose C
implementation conforms perfectly to the letter of the standard, but
in as perverse a way as (in)humanly possible. For example, invoking
undefined behavior on a DS9K really does make demons fly out of your
nose, and CHAR_BIT is a prime number (greater than 8, of course) that
may change when you recompile your program.

<http://dspace.dial.pipex.com/town/green/gfd34/art/>
<http://en.wikipedia.org/wiki/DeathStation_9000>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"David T. Ashley" <dt*@e3ft.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"David T. Ashley" <dt*@e3ft.comwrites:

>
First, until relatively recently, 32-bit integers were entrenched, and
this
could be assumed on just about every platform. So, a book author using
non-portable code like this can be excused. Second, a book author might
do
this for simplicity -- to avoid examples that distract from the concept
s/he
is trying to present in that example or chapter.

[...]

I disagree. A book author, of all people, should know better than to
make undocumented assumptions like this. All the world never was a
VAX, and all the world is not an x86 now.

I disagree with you. It has always been a justifiable tool in teaching to
ignore or abstract to oblivion facts that aren't relevant or would distract
from what one is trying to teach at that moment. Even V=IR isn't strictly
true when you look at it closely enough. But it is close enough for most
applications. (And the current into the inputs of an op-amp is NOT zero.)

[snip]

Integers are always 32 bits and the largest positive integer is always
0x7FFFFFFF. Seems harmless enough to me, and it will work until the student
needs to know otherwise.

Do you mean "integers", or specifically the type "long int"?

The problem is that far too many programmers never unlearn the "fact"
that a given type is "always" 32 bits -- and they get away with it for
far too long by working on systems where it happens to be correct.

Note that K&R1 has a table of the sizes of the predefined types on the
second page of the chapter on types, operators, and expressions.

I understand the need to gloss over some details in the early stages
of teaching (though I don't think it's necessary to lie). But the
assumption that LONG_MAX==0x7FFFFFFF isn't even a particularly
*usepful* lie. If you don't want to explain that different types have
different sizes on different systems, why not just ignore the issue
rather than lying about it? "Use int to count things. Use long int
to count lots of things".

I suspect neither of us is going to change the other's mind.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

"David T. Ashley" <dt*@e3ft.comwrites:

>"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11**********************@m58g2000cwm.googleg roups.com...

>
It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

The Deathstation 9000 (DS9K) is a mythical computer system whose C
implementation conforms perfectly to the letter of the standard, but
in as perverse a way as (in)humanly possible. For example, invoking
undefined behavior on a DS9K really does make demons fly out of your
nose, and CHAR_BIT is a prime number (greater than 8, of course) that
may change when you recompile your program.

<http://dspace.dial.pipex.com/town/green/gfd34/art/>

This Web site is mentioned...

<http://en.wikipedia.org/wiki/DeathStation_9000>

....in this article as having been created "probably as an April Fool's Day
joke". I would like to state for the record that there is no "probably"
about it. Since the two people who created it (in the last week of March
2000) are very easily discovered if one looks hard enough, I am surprised
that this wasn't researched more thoroughly.

All right, I confess. No, I'm not surprised in the least that I should
discover an example of poor research on Wikipedia.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Malcolm McLean wrote:

"David T. Ashley" <dt*@e3ft.comwrote in message

>"Peter Nilsson" <ai***@acay.com.auwrote in message

>>It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

It is machine invented by a former reg called Kaz Kazsomethingorother
- he had an Arabic surname I never worked out how to pronounce -
which implements a C compiler as perversely as possible, though
fully conforming. So it would use sign magnitude representation
instead of two's complement, for instance.

See: http://dialspace.dial.pipex.com/town/green/gfd34/art/

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

"David T. Ashley" <dt*@e3ft.comwrote in message

>"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11**********************@m58g2000cwm.googleg roups.com...

>>>
It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

It is machine invented by a former reg called Kaz Kazsomethingorother - he
had an Arabic surname I never worked out how to pronounce - which implements
a C compiler as perversely as possible, though fully conforming.
So it would use sign magnitude representation instead of two's complement,
for instance.

>>>More simply (-1u >1).

Would naturally cause a trap representation and program termination.

Would it? I thought -1u (and David T Ashley's original (unsigned)-1)
are always valid unsigned values. The shift of an unsigned value
can't result in a trap representation. OK, -1u >1 is not always ==
INT_MAX, but it is always defined.

--
Ben.

[fdmfdmfdm]

On Feb 2, 8:37 pm, Ben Pfaff <[e-mail]:

"[e-mail]" <[e-mail]:

let's say without checking including files, how do we to represent the
biggest say int in a system?

Why not use header files? That's what they're there for.
INT_MAX from <limits.his perfect for the purpose.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

OMG, too many answers. Actually, my original intention is to ask: how
many bit will be in 0x7FFFFFFF, without considering leading 0s (let's
assume they are not added), I think this long integer is 32 bits, am I
right?

[santosh]

fd*******@gmail.com wrote:

On Feb 2, 8:37 pm, Ben Pfaff <[e-mail]:

"[e-mail]" <[e-mail]:

let's say without checking including files, how do we to represent the
biggest say int in a system?

Why not use header files? That's what they're there for.
INT_MAX from <limits.his perfect for the purpose.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

OMG, too many answers. Actually, my original intention is to ask: how
many bit will be in 0x7FFFFFFF, without considering leading 0s (let's
assume they are not added), I think this long integer is 32 bits, am I
right?

It's not a long integer. It's a numerical value in base 16. In C
source, it's treated as a hexadecimal constant value. Without a size
suffix, it's assigned the smallest integer type that can hold the
value. What that will be depends on your implementation. It might be
int or long. If you want the value to be treated as type long then add
the L or l suffix to it.

Atleast 32 bits are required to represent the value, but whether the
object that gets assigned the value in the source is int or long or
long long will depend on the programmer and the implementation limits.
In C, long is guaranteed to be atleast 32 bits, so it'll safely hold
the above value. An int may or may not, depending on it's range,
(which is 32 bits on most modern desktop processors).

[Joe Wright]

fd*******@gmail.com wrote:

On Feb 2, 8:37 pm, Ben Pfaff <[e-mail]:

>"[e-mail]" <[e-mail]:

>>let's say without checking including files, how do we to represent the
biggest say int in a system?

Why not use header files? That's what they're there for.
INT_MAX from <limits.his perfect for the purpose.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

OMG, too many answers. Actually, my original intention is to ask: how
many bit will be in 0x7FFFFFFF, without considering leading 0s (let's
assume they are not added), I think this long integer is 32 bits, am I
right?

01111111 11111111 11111111 11111111

31 bits?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

"fd*******@gmail.com" <fd*******@gmail.comwrites:
[...]

OMG, too many answers. Actually, my original intention is to ask: how
many bit will be in 0x7FFFFFFF, without considering leading 0s (let's
assume they are not added), I think this long integer is 32 bits, am I
right?

The value 0x7FFFFFFF has 31 1-bits, 4 for each 'F' and 3 for the '7'.
That means it requires at least a 32-bit signed type to store it
(adding 1 bit for the sign bit), or at least a 31-bit unsigned type.
(Yes, a 31-bit unsigned type is theoretically possible, with
CHAR_BIT==31 and sizeof(unsigned)==1, or with padding bits.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

"Malcolm McLean" <re*******@btinternet.comwrote:

"David T. Ashley" <dt*@e3ft.comwrote in message

"Peter Nilsson" <ai***@acay.com.auwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...

>
It will work on vanilla machines, but it won't work on death stations.

What is a "death station"?

It is machine invented by a former reg called Kaz Kazsomethingorother - he
had an Arabic surname I never worked out how to pronounce

Kaz Kylheku. And I think it's Slavic, not Arabic - IIRC the Kaz stands
for Kazimir.

Richard

[Jorge Peixoto de Morais Neto]

On Feb 3, 1:33 am, "Peter Nilsson" <[e-mail]:

"David T. Ashley" <[e-mail]:

<[e-mail]

let's say without checking including files, how do we torepresentthe
>biggestsay int in asystem?

And how exactly do you expect to write portable code if you're going to
ignore thesystemprovisions that were designed to facilitate that goal?
You can do it in this case, but not in all cases.

I ran across a book give this code:

long intbiggest= 0x7FFFFFFF;

<snip>

The safest way to deal with this is to use the constants in <limits.h>.

The second-safest way

[With clear daylight behind the safest way...]

(since just about every platform is 2's complement
these days) is to use some expression that automatically sizes to the
native integer size. Off the top of my head,

((unsigned)-1 >1)

might work.

More simply (-1u >1).

It will work on vanilla machines, but it won't work on death stations.
UINT_MAX == INT_MAX is allowed. UINT_MAX 4 * INT_MAX is
allowed. [UINT_MAX >= INT_MAX is required.]

It is possible to 'compute' the maximum value of int on a C90
implementation... [method from Lawrance Kirby]

int int_max(void)
{
unsigned u = -1;
int i;
while ((i = u) < 0 || i != u) u /= 2;
return i;
}

Pardon my ignorance, but what is the point of tesing i!=u right after
doing i=u?

>
...but it cannot be done portably as a constant expression.

--
Peter

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Jorge Peixoto de Morais Neto wrote:

On Feb 3, 1:33 am, "Peter Nilsson" <[e-mail]:

"David T. Ashley" <[e-mail]:

<[e-mail]
let's say without checking including files, how do we torepresentthe
biggestsay int in asystem?

And how exactly do you expect to write portable code if you're going to
ignore thesystemprovisions that were designed to facilitate that goal?
You can do it in this case, but not in all cases.

I ran across a book give this code:

long intbiggest= 0x7FFFFFFF;

<snip>

The safest way to deal with this is to use the constants in <limits.h>.

The second-safest way

[With clear daylight behind the safest way...]

(since just about every platform is 2's complement
these days) is to use some expression that automatically sizes to the
native integer size. Off the top of my head,

((unsigned)-1 >1)

might work.

More simply (-1u >1).

It will work on vanilla machines, but it won't work on death stations.
UINT_MAX == INT_MAX is allowed. UINT_MAX 4 * INT_MAX is
allowed. [UINT_MAX >= INT_MAX is required.]

It is possible to 'compute' the maximum value of int on a C90
implementation... [method from Lawrance Kirby]

int int_max(void)
{
unsigned u = -1;
int i;
while ((i = u) < 0 || i != u) u /= 2;
return i;
}

Pardon my ignorance, but what is the point of tesing i!=u right after
doing i=u?

It becomes clearer when you make some implicit conversions explicit:

while ((i = (signed int) u) < 0 || ((unsigned int) i) != u) u /= 2;

In other words, it tests whether the unsigned number has changed by
converting it to signed int.

[Old Wolf]

On Feb 3, 10:37 am, Ian Collins <[e-mail]:

>
#include <stdio.h>

int main(void)
{
int i = (int)((-1U)>>1);
long l = (long)((-1UL)>>1);

printf("%x %lx\n", i, l);
}

1. Why the useless casts?
2. You cause UB by passing signed values for %x which expects
unsigned.
3. The value you compute is not guaranteed to be the maximum.

[Ian Collins]

Old Wolf wrote:

On Feb 3, 10:37 am, Ian Collins <[e-mail]:

>>#include <stdio.h>

int main(void)
{
int i = (int)((-1U)>>1);
long l = (long)((-1UL)>>1);

printf("%x %lx\n", i, l);
}

1. Why the useless casts?
2. You cause UB by passing signed values for %x which expects
unsigned.
3. The value you compute is not guaranteed to be the maximum.

You snipped The scene setting "something like the following abomination".

--
Ian Collins.