Integer Sizes?
Craig Broadbooks
according to the following assumptions:
a char is always 8 bits
a short is always 16 bits
a long is always 32 bits
an int is the width of the word of the processor it's compiled on(i.e. 16
bits in DOS, 32 for WIN32, etc.)
At my company, we just started developing for the PlayStation 2. Its
processor uses a 64 bit instruction set. The compiler used is a hybrid GNU
compiler. It treats the long and the int different than I would expect. It
considers a long as 64 bits and an int as 32 bits. This is contrary to how
any of use believed it should work. So I decided to look through the
Standard C draft c9x for some clarification. The most useful thing I found
was in the section describing integer limits. Here is an excerpt or what I
found:
-- minimum value for an object of type int
INT_MIN -32767 // -(215-1)
-- maximum value for an object of type int
INT_MAX +32767 // 215-1
-- maximum value for an object of type unsigned int
UINT_MAX 65535 // 216-1
-- minimum value for an object of type long int
LONG_MIN -2147483647 // -(231-1)
-- maximum value for an object of type long int
LONG_MAX +2147483647 // 231-1
-- maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232-1
-- minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // -(263-1)
-- maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263-1
-- maximum value for an object of type unsigned long long
int
ULLONG_MAX 18446744073709551615 // 264-1
This is close to what I expected to find, though adds some confusion. The
only thing I don't understand is the limits for int. They imply that an int
is 16 bits wide, not system dependent.
Could someone shed some light on this? Is an int's width system dependent?
I would like to know if you use the long keyword are you guaranteed to get a
32 bit value? In the future are you guaranteed to get a 64 bit value when
using a long long? Does anyone know what will happen when we start using
128 bit values? Will they add a long long long? I noticed that the c9x
draft did create the following new types in stdint.h: int8_t, int16_t,
int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t. Is this the how
these issues are being addressed? Any idea when the major compilers will
start supporting any of these types?
Thanks,
Craig
Paul Jarc
> This is close to what I expected to find, though adds some confusion. The
> only thing I don't understand is the limits for int. They imply that an int
> is 16 bits wide, not system dependent.
All sizes are system-dependant. The limits given in the standard are
the smallest that those types are allowed to be; they are all allowed
to be larger. Also, note that the range of values they can
accommodate places a lower bound on their size, but they can also have
padding bits (except for character types), making them larger than you
might expect.
> I would like to know if you use the long keyword are you guaranteed to get a
> 32 bit value?
No. But in C99, you'll have int32_t, which is exactly 32 bits, if it
exists. (That doesn't include any padding bits that might be part of
that type.) You can test whether it exists by using `#include <limits.h>'
and `#ifdef INT32_MAX'.
> In the future are you guaranteed to get a 64 bit value when using a
> long long?
No. long long is at least 64 bits; use int64_t for an exact type, and
use intmax_t for the largest type.
> Does anyone know what will happen when we start using 128 bit
> values? Will they add a long long long?
Hopefully not. We should be able to add int128_t without breaking
anything.
> I noticed that the c9x draft did create the following new types in
> stdint.h: int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t,
> uint32_t, uint64_t. Is this the how these issues are being
> addressed?
Actually, those are typedefs, not distinct types, so that uint8_t will
typically be the same type as unsigned char. But yes, these type
names will allow you to say what you really mean better than using
bare ints and longs.
> Any idea when the major compilers will start supporting any of these
> types?
I think some already do, or have similar schemes.
paul
Douglas A. Gwyn
> I like most programmers have been using ints, longs, shorts and chars
> according to the following assumptions:
> a char is always 8 bits
> a short is always 16 bits
> a long is always 32 bits
I would hope that most C programmers know that those are *minimum*
widths, not *exact* widths.
> [PlayStation-2 GCC] considers a long as 64 bits and an int as 32 bits.
That's an eminently reasonable implementation choice for that platform.
> -- maximum value for an object of type int ... [etc.]
Those are minimum required maxima etc., not exact maxima etc.
> Is an int's width system dependent?
Very! It has to be at least 16 bits and no greater than that of long.
> I would like to know if you use the long keyword are you guaranteed to get a
> 32 bit value? In the future are you guaranteed to get a 64 bit value when
> using a long long?
The guarantee is that the width will be *at least* that.
> draft did create the following new types in stdint.h: int8_t, int16_t,
> int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.
Those aren't new types; they're typedefs for existing types.
The intent is that you use these typedefs when you need to specify
particular widths.
If you don't have <inttypes.h> or <stdint.h> on your system,
it is easy enough to roll your own; I've published these and other
often-missing pieces of the C9x library environment at:
Clive D.W. Feather
<cra...@solworks.com> writes
>I like most programmers have been using ints, longs, shorts and chars
>according to the following assumptions:
>
>a char is always 8 bits
>a short is always 16 bits
>a long is always 32 bits
Those assumptions are wrong.
>The most useful thing I found
>was in the section describing integer limits. Here is an excerpt or what I
>found:
You've misunderstood: these are the *minimum* (absolute) values for the
minima and maxima. Not the exact requirements.
> -- minimum value for an object of type int
> INT_MIN -32767 // -(215-1)
> -- maximum value for an object of type int
> INT_MAX +32767 // 215-1
Thus (int) must be able to hold values in [-32767, +32767], but could
have any size of at least 16 bits.
>Could someone shed some light on this? Is an int's width system dependent?
Yes.
>I would like to know if you use the long keyword are you guaranteed to get a
>32 bit value?
No. You are guaranteed at least 32 bits.
>In the future are you guaranteed to get a 64 bit value when
>using a long long?
No. You are guaranteed at least 64 bits.
>I noticed that the c9x
>draft did create the following new types in stdint.h: int8_t, int16_t,
>int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t. Is this the how
>these issues are being addressed?
Yes.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Peter Seebach
Craig Broadbooks <cra...@solworks.com> wrote:
>I like most programmers have been using ints, longs, shorts and chars
>according to the following assumptions:
>a char is always 8 bits
>a short is always 16 bits
>a long is always 32 bits
>an int is the width of the word of the processor it's compiled on(i.e. 16
>bits in DOS, 32 for WIN32, etc.)
You've been wrong, very wrong.
>At my company, we just started developing for the PlayStation 2. Its
>processor uses a 64 bit instruction set. The compiler used is a hybrid GNU
>compiler. It treats the long and the int different than I would expect. It
>considers a long as 64 bits and an int as 32 bits.
This is not merely acceptable within the standard, it is *VERY WISE*.
Hint:
long l = (long) int_value * other_int_value;
will generally not overflow. ;)
>This is contrary to how
>any of use believed it should work.
You were all silly people.
>This is close to what I expected to find, though adds some confusion. The
>only thing I don't understand is the limits for int. They imply that an int
>is 16 bits wide, not system dependent.
You have misunderstood them.
>Could someone shed some light on this? Is an int's width system dependent?
Yes.
The limits there are the *MINIMUM* limits. They specify the *smallest* range.
Thus, *every* platform is such that
INT_MAX >= 32767;
but *not* every platform is such that
INT_MAX <= 32767;
and indeed, on many, it's larger.
>I would like to know if you use the long keyword are you guaranteed to get a
>32 bit value?
You are guaranteed to get a range that can represent *at least* 32-bit
numbers.
>In the future are you guaranteed to get a 64 bit value when
>using a long long?
Same deal; *at least* 64. 128 is fine. 1024 is fine. 32,000 bits is fine.
>Does anyone know what will happen when we start using
>128 bit values?
int128_t, or 'long long' will grow, or there will be riots.
>Will they add a long long long? I noticed that the c9x
>draft did create the following new types in stdint.h: int8_t, int16_t,
>int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t. Is this the how
>these issues are being addressed? Any idea when the major compilers will
>start supporting any of these types?
Many of them already do, and you can probably get them on your platform with
typedef char int8_t;
typedef long int64_t;
in the mean time. :)
Basically, you've been living in a small, specialized, subset of the world for
too long. Find a copy of Spencer's wonderful 10 Commandments for C
Programmers, and read, and re-read, the one about "all the world's a VAX".
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Paul Jarc
> Basically, you've been living in a small, specialized, subset of the
> world for too long. Find a copy of Spencer's wonderful 10
> Commandments for C Programmers, and read, and re-read, the one about
> "all the world's a VAX".
Available at <URL:http://www.lysator.liu.se/c/ten-commandments.html>.
paul
Francis Glassborow
<se...@plethora.net> writes
>Basically, you've been living in a small, specialized, subset of the world for
>too long. Find a copy of Spencer's wonderful 10 Commandments for C
>Programmers, and read, and re-read, the one about "all the world's a VAX".
However there is one thing in the original writer's favour he finally
saw enough light to come here. I do wish programmers would learn the
requirements of the language they opt to use instead of deducing 'facts'
by experimenting. IOWs stop asking your compiler what is correct and
start reading some definitive sources.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Stephen Baynes
> However there is one thing in the original writer's favour he finally
> saw enough light to come here. I do wish programmers would learn the
> requirements of the language they opt to use instead of deducing 'facts'
> by experimenting. IOWs stop asking your compiler what is correct and
> start reading some definitive sources.
Good sentiments, but how many programmers actually have access to the
definitive source (the ISO C standard)? In this case any good (but not
platform specific) book on C would do - but you can't call such books
definitive (except perhaps for the original K&R).
--
Stephen Baynes CEng MBCS Stephen...@soton.sc.philips.com
Philips Semiconductors Ltd
Southampton SO15 0DJ +44 (0)23 80316431 *** NEW ***
United Kingdom My views are my own.
Do you use ISO8859-1? Yes if you see © as copyright, ÷ as division and ½ as 1/2.
Francis Glassborow
<stephen...@soton.sc.philips.com> writes
>Good sentiments, but how many programmers actually have access to the
>definitive source (the ISO C standard)?
I expect engineers to know their standards. I do not expect
professional electricians to be swapping live and neutral wires on the
basis that it 'works' nor do I expect them to lay wires in walls other
than vertically or horizontally.
However it has long been clear that most programmers are (sometimes
gifted) amateurs :(
Stephen Baynes
>
> In article <383CFEBC...@soton.sc.philips.com>, Stephen Baynes
> <stephen...@soton.sc.philips.com> writes
> >Good sentiments, but how many programmers actually have access to the
> >definitive source (the ISO C standard)?
>
> I expect engineers to know their standards. I do not expect
> professional electricians to be swapping live and neutral wires on the
> basis that it 'works' nor do I expect them to lay wires in walls other
> than vertically or horizontally.
I agree they should know the standards.
There is a difference between knowing the standard and having access to
the definitive document. How many electricians have a copy of the appropriate
regulations compared to how many have a book on the subject or have
been on a training course that has imparted knowledge of the regulations?
If they all carry a copy of the regulations then why don't programmers.
Is it a reflection on the profession or on the standardization process?
>
> However it has long been clear that most programmers are (sometimes
> gifted) amateurs :(
I agree the sentiment.
Clive D.W. Feather
<p...@po.cwru.edu> writes
>No. But in C99, you'll have int32_t, which is exactly 32 bits, if it
>exists. (That doesn't include any padding bits that might be part of
>that type.) You can test whether it exists by using `#include <limits.h>'
>and `#ifdef INT32_MAX'.
Wrong header: you want <stdint.h> (which is included by <inttypes.h>).
Peter Curran
<fra...@robinton.demon.co.uk> wrote:
>In article <383CFEBC...@soton.sc.philips.com>, Stephen Baynes
><stephen...@soton.sc.philips.com> writes
>>Good sentiments, but how many programmers actually have access to the
>>definitive source (the ISO C standard)?
>
>I expect engineers to know their standards. I do not expect
>professional electricians to be swapping live and neutral wires on the
>basis that it 'works' nor do I expect them to lay wires in walls other
>than vertically or horizontally.
>
>However it has long been clear that most programmers are (sometimes
>gifted) amateurs :(
There is a major difference between the electrical codes and
programming language standards - the electrical codes have been proven
by many years of experience and tens or hundreds of millions of
applications, to be useful, workable, comprehensible, etc. Programming
language standards don't meet any of those goals, to anywhere near the
same degree of credibility.
I'm probably going to stamp on more toes here, but IMHO the C standard
is particularly suspect - the combined experience of the committee and
effective contributors is, from my understanding, far less than for
other major language standards - Fortran, COBOL, even Ada, for
example. The committee's claim to credibility and acceptance is far
less supportable than that of most engineering standards, as far as I
can tell. (In case it isn't clear, this is a comment on the process,
not on any individual or even the committee.)
--
Peter Curran pcu...@acm.gov (chg gov=>org)
Don Bockenfeld
integral types. There is perhaps a deeper issue here. The software I write
must run on an embedded system where all of the cards and the backplane
interface were designed by my company. The nature of our hardware imposes
restrictions on our choice of compilers. We MUST be able to perform 32-bit
transfers. Although a compiler could be fully compliant with the C standard
and not support 32-bit data transfers, we wouldn't buy it.
Our driver design involves defining typedefs for each of the required
hardware interface types. Standard integral types are used to pass data in
and out of the driver functions; but these functions cast to or from the
special typedefs as close to the actual hardware access as possible.
Theoretically, all we need to do to support a different compiler is redefine
the typedefs as needed. (I say theoretically because we haven't had any
reason to change compilers yet.)
I understand that C99 defines a standard syntax for this sort of
hardware-interface type and even handles defining the types appropriately.
Thanks!
Craig Broadbooks wrote in message ...
>I like most programmers have been using ints, longs, shorts and chars
>according to the following assumptions:
>a char is always 8 bits
>a short is always 16 bits
>a long is always 32 bits
>an int is the width of the word of the processor it's compiled on(i.e. 16
>bits in DOS, 32 for WIN32, etc.)
<snip>
>At my company, we just started developing for the PlayStation 2. Its
>processor uses a 64 bit instruction set. The compiler used is a hybrid GNU
>compiler. It treats the long and the int different than I would expect.
It
>considers a long as 64 bits and an int as 32 bits.
<snip>
James Kuyper Jr.
...
> integral types. There is perhaps a deeper issue here. The software I write
> must run on an embedded system where all of the cards and the backplane
> interface were designed by my company. The nature of our hardware imposes
> restrictions on our choice of compilers. We MUST be able to perform 32-bit
> transfers. Although a compiler could be fully compliant with the C standard
> and not support 32-bit data transfers, we wouldn't buy it.
>
> Our driver design involves defining typedefs for each of the required
> hardware interface types. Standard integral types are used to pass data in
> and out of the driver functions; but these functions cast to or from the
> special typedefs as close to the actual hardware access as possible.
> Theoretically, all we need to do to support a different compiler is redefine
> the typedefs as needed. (I say theoretically because we haven't had any
> reason to change compilers yet.)
>
> I understand that C99 defines a standard syntax for this sort of
> hardware-interface type and even handles defining the types appropriately.
> Thanks!
In theory, that depends upon your definition of "appropriately". The C
standard requires that int32_t, if it exists, have a width of exactly 32
bits. You need to check "#ifdef INT32_MAX", to be sure that it exists.
That doesn't mean that it has a size of 32 bits - it could be a 36-bit
type with 4 padding bits. The standard provides no typedefs for
exact-sized types. Typically, for the kind of application you're talking
about, you need a type whose width is guaranteed to be the same as it's
size - check "if(sizeof(int32_t)*CHAR_BIT==32)" to make sure. The
standard guarantees such a relationship only for 'unsigned char'.
In practice, if your platform has hardware support for 32-bit types
(which seems likely, if you need them for your hardware interfaces) then
an implementor would have to be an idiot not to use that type for
int32_t. Of course, there are idiots out there.
Nick Maclaren
In article <3843D0FA...@wizard.net>, "James Kuyper Jr." <kuy...@wizard.net> writes:
|> Don Bockenfeld wrote:
|> ...
|> > integral types. There is perhaps a deeper issue here. The software I write
|> > must run on an embedded system where all of the cards and the backplane
|> > interface were designed by my company. The nature of our hardware imposes
|> > restrictions on our choice of compilers. We MUST be able to perform 32-bit
|> > transfers. Although a compiler could be fully compliant with the C standard
|> > and not support 32-bit data transfers, we wouldn't buy it.
|> >
|> > hardware-interface type and even handles defining the types appropriately.
|> > Thanks!
|>
|> In theory, that depends upon your definition of "appropriately". The C
|> standard requires that int32_t, if it exists, have a width of exactly 32
|> bits. You need to check "#ifdef INT32_MAX", to be sure that it exists.
|> That doesn't mean that it has a size of 32 bits - it could be a 36-bit
|> type with 4 padding bits. The standard provides no typedefs for
|> exact-sized types. Typically, for the kind of application you're talking
|> about, you need a type whose width is guaranteed to be the same as it's
|> size - check "if(sizeof(int32_t)*CHAR_BIT==32)" to make sure. The
|> standard guarantees such a relationship only for 'unsigned char'.
Even more seriously, it doesn't guarantee that the bit order is what
you may expect. Nor does it require that the overflow behaviour is
what you might expect, except for unsigned types.
It is perfectly possible (even, sometimes, reasonable) for a compiler
to have an integer type that doesn't correspond with the hardware.
For example, to have a big-endian integer on hardware that is little-
endian, or where the type raises SIGFPE on overflow but the hardware
silently wraps.
|> In practice, if your platform has hardware support for 32-bit types
|> (which seems likely, if you need them for your hardware interfaces) then
|> an implementor would have to be an idiot not to use that type for
|> int32_t. Of course, there are idiots out there.
Yes. And there ARE good reasons for doing things differently, in
some cases. Such as in a compiler designed for developing code to
run on a different platform, or range of platforms.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Douglas A. Gwyn
> In article <3843D0FA...@wizard.net>, "James Kuyper Jr." <kuy...@wizard.net> writes:
> |> The C standard requires that int32_t, if it exists, have a
> |> a size of 32 bits - it could be a 36-bit type with 4 padding
> |> bits.
> what you may expect. Nor does it require that the overflow
> behaviour is what you might expect, except for unsigned types.
Actually, it requires the *exact*-width types to have unpadded
twos-complement representation.
Overflow is undefined behavior for all C signed integer types.
Nick Maclaren
Precisely. Twos' complement representation does not define a bit
order, and undefined behaviour is something that you might not
expect (almost by definition.)
James Kuyper
>
> Nick Maclaren wrote:
> > In article <3843D0FA...@wizard.net>, "James Kuyper Jr." <kuy...@wizard.net> writes:
> > |> The C standard requires that int32_t, if it exists, have a
> > |> width of exactly 32 bits. ... That doesn't mean that it has
> > |> a size of 32 bits - it could be a 36-bit type with 4 padding
> > |> bits.
> > Even more seriously, it doesn't guarantee that the bit order is
> > what you may expect. Nor does it require that the overflow
> > behaviour is what you might expect, except for unsigned types.
>
> Actually, it requires the *exact*-width types to have unpadded
> twos-complement representation.
I can see that twos-complement representation is implied by the
requirements on INT*_MIN and INT*_MAX, but I couldn't find the
prohibition on padding bits. Is that a change from n869?
Is the final draft of the standard publically available yet? If not, how
soon?
Douglas A. Gwyn
> "Douglas A. Gwyn" wrote:
> > Actually, it requires the *exact*-width types to have unpadded
> > twos-complement representation.
It was a last-minute change based on feedback from reviewers
of the preliminary spec.
Marc van Leeuwen
> >Nick Maclaren wrote:
> >> Even more seriously, it doesn't guarantee that the bit order is
> >> what you may expect. Nor does it require that the overflow
> >> behaviour is what you might expect, except for unsigned types.
> >
> >twos-complement representation.
> >
>
> Precisely. Twos' complement representation does not define a bit
> order, and undefined behaviour is something that you might not
> expect (almost by definition.)
That's the second time you mention bit order. Since C does not assume
bit-addressable memory, I don't see what you could be hinting at. I would
expect something like 1<<6==0x40 to always hold; are you saying this is not
justified?
As regards the physical location of bits, I assume they are either in separate
memory chips arranged in an orderly array inside my computer, or in banks
within the same memory chip, but frankly, I couldn't care less.
--
Marc van Leeuwen
Universite de Poitiers
http://wwwmathlabo.univ-poitiers.fr/~maavl/
Nick Maclaren
In article <3844F033...@mathlabo.univ-poitiers.fr>, Marc van Leeuwen <ma...@mathlabo.univ-poitiers.fr> writes:
|> Nick Maclaren wrote:
|> > >Nick Maclaren wrote:
|> > >> Even more seriously, it doesn't guarantee that the bit order is
|> > >> what you may expect. Nor does it require that the overflow
|> > >> behaviour is what you might expect, except for unsigned types.
|> > >
|> > >Actually, it requires the *exact*-width types to have unpadded
|> > >twos-complement representation.
|> > >
|> > >Overflow is undefined behavior for all C signed integer types.
|> >
|> > Precisely. Twos' complement representation does not define a bit
|> > order, and undefined behaviour is something that you might not
|> > expect (almost by definition.)
|>
|> That's the second time you mention bit order. Since C does not assume
|> bit-addressable memory, I don't see what you could be hinting at. I would
|> expect something like 1<<6==0x40 to always hold; are you saying this is not
|> justified?
No, that is not the issue. You clearly have not thought of the
problem of handling external data formats, which was the rationale
for introducing the exact-width data types in the first place.
A device driver or external file data object of 32 bits long will
contain those bits in a certain order. There is no requirement for
that to be the same order that is used by C. Some people say that
it would be crazy for an implementor to do anything different, but
they are assuming that there is only ONE reasonable order. This is
not generally true.
The matter of byte ordering is too well-known to go into details;
it is common for the external value 1 when loaded as a uint32_t
to be 16777216. I have used systems where both big-endian and
little-endian bit orders WITHIN A BYTE were possible. There is no
particularly reason for integers to be separated into bytes in the
numerical order, either, and consecutive integer bits might well be
assigned to bytes in a round-robin fashion.
|> As regards the physical location of bits, I assume they are either in separate
|> memory chips arranged in an orderly array inside my computer, or in banks
|> within the same memory chip, but frankly, I couldn't care less.
That is exactly my view for most of my code - i.e. the code that does
not have to interface to an external data format. It doesn't use
exact width integer types and doesn't need to. Now please tell me
why you want exact width integer types in an application that does
NOT have to interface to an external data format?
David R Tribble
> There is a major difference between the electrical codes and
> programming language standards - the electrical codes have been proven
> by many years of experience and tens or hundreds of millions of
> applications, to be useful, workable, comprehensible, etc. Programming
> language standards don't meet any of those goals, to anywhere near the
> same degree of credibility.
>
> I'm probably going to stamp on more toes here, but IMHO the C standard
> is particularly suspect - the combined experience of the committee and
> effective contributors is, from my understanding, far less than for
> other major language standards - Fortran, COBOL, even Ada, for
> example. The committee's claim to credibility and acceptance is far
> less supportable than that of most engineering standards, as far as I
> can tell. (In case it isn't clear, this is a comment on the process,
> not on any individual or even the committee.)
Okay, I'll bite.
(Reading the ANSI COBOL-85 spec doesn't lead me to the conclusion
that the members of that committee were any more gifted or
experienced than the members of ISO C. Perhaps you're referring to
the relative age of the languages, since it would be easy to find
someone who has programmed in COBOL for 35 years, but impossible
for C? FWIW, the resulting ISO C standards texts are far more
readable and understandable than the ANSI COBOL standards, in my
opinion.)
So:
In what ways are the standardization and acceptance processes of
the ISO C committee inferior to the FORTRAN/COBOL/Ada standardization
processes?
-- David R. Tribble, da...@tribble.com, http://david.tribble.com --
Dennis Ritchie
> ... No, that is not the issue. You clearly have not thought of the
> problem of handling external data formats, which was the rationale
> for introducing the exact-width data types in the first place.
>
> A device driver or external file data object of 32 bits long will
> contain those bits in a certain order. There is no requirement for
> that to be the same order that is used by C...
>
> The matter of byte ordering is too well-known to go into details;
> it is common for the external value 1 when loaded as a uint32_t
> to be 16777216. I have used systems where both big-endian and
> little-endian bit orders WITHIN A BYTE were possible....
Maybe by the time of the C0X standard, things will be pinned
down well enough that it will become possible actually to
write a TCP/IP stack, or conceivably an entire operating
system in C. One might even imagine that it runs on several
different machine architectures. A hope for the new milennium.
Dennis
Douglas A. Gwyn
> Marc van Leeuwen <ma...@mathlabo.univ-poitiers.fr> writes:
> |> Nick Maclaren wrote:
> |> That's the second time you mention bit order. Since C does not
> |> assume bit-addressable memory, I don't see what you could be
> No, that is not the issue. You clearly have not thought of the
> problem of handling external data formats, which was the rationale
> for introducing the exact-width data types in the first place.
> A device driver or external file data object of 32 bits long will
> contain those bits in a certain order. There is no requirement for
> that to be the same order that is used by C.
I assumed Nick meant byte order within multiple-byte integer formats.
Bit "order" within a byte is pointless; there is a LSB and an MSB,
but any *labels* such as "bit number 0" are pure conventions. One
handles such conventions by figuring out what they mean in observable
terms.
The exact-width *typedefs* were not meant to completely solve all
issues for externally-imposed integer formats. The committee did
discuss what it would take to adequately address these, and decided
that we didn't want to extend the type system that far this time
around. We hope that there will be some experimentation in this
area, so that there will be guidance about the practicality of
various technical approaches to this in time to consider something
along these lines for the next revision of the C standard.
Peter Curran
--
Peter Curran
Basically, the number of people involved. From my recollection of the
reports on these standards (and I have read the history, but my memory
may be flawed) the number of people involved in developing the
Fortran/COBOL/Ada standards far exceeded the number involved in C.
Sheer numbers doesn't guarantee quality, of course, but in these cases
I think there is reason to believe that the wider range of experience
was beneficial to the processes.
Nick Maclaren
>> problem of handling external data formats, which was the rationale
>> for introducing the exact-width data types in the first place.
>>
>> A device driver or external file data object of 32 bits long will
>> contain those bits in a certain order. There is no requirement for
>>
>> The matter of byte ordering is too well-known to go into details;
>> it is common for the external value 1 when loaded as a uint32_t
>> to be 16777216. I have used systems where both big-endian and
>> little-endian bit orders WITHIN A BYTE were possible....
>
>Maybe by the time of the C0X standard, things will be pinned
>down well enough that it will become possible actually to
>write a TCP/IP stack, or conceivably an entire operating
>system in C. One might even imagine that it runs on several
>different machine architectures. A hope for the new milennium.
Yes :-)
More seriously, the way that this is traditionally handled is variant
code - this can be classified either by machine type or by property.
For example, the ntol etc. macros are specifically intended to cover
up the bit ordering problems, but (as with offsetof) their internals
have to be regarded as 'black magic'. [This is background for other
readers, obviously.]
My objection to the C99 exact width types are that they are a gesture
in the direction of being able to write such things as TCP/IP stacks
in clean, system-independent code. Unfortunately, they are no more
than a gesture, because of the problems that I mentioned, which will
not stop them being used without understanding of their restrictions.
This will then lead to MORE endian-dependent code and not less :-(
Nick Maclaren
>> Marc van Leeuwen <ma...@mathlabo.univ-poitiers.fr> writes:
>> |> Nick Maclaren wrote:
>> |> > Twos' complement representation does not define a bit order, ...
>> |> That's the second time you mention bit order. Since C does not
>> |> assume bit-addressable memory, I don't see what you could be
>> No, that is not the issue. You clearly have not thought of the
>> problem of handling external data formats, which was the rationale
>> for introducing the exact-width data types in the first place.
>> A device driver or external file data object of 32 bits long will
>> contain those bits in a certain order. There is no requirement for
>
>I assumed Nick meant byte order within multiple-byte integer formats.
>Bit "order" within a byte is pointless; there is a LSB and an MSB,
>but any *labels* such as "bit number 0" are pure conventions. One
>handles such conventions by figuring out what they mean in observable
>terms.
No, you have missed the point. I have used interfaces where the next
byte contained a length in the range 0-63 stored as binary. But the
bits were in the other order from the ones that you got by loading the
value into C. I.e. the length of 3 appeared in C as 192 and vice
versa.
Andrew F. Vesper
From _The Notebooks of Lazarus Long_, by Robert A. Heinlein:
Democracy is based on the assumption that a million men are
wiser than one man. How's that again? I missed something.
Of course, the next aphorism is:
Autocracy is based on the assumption that one man is
wiser than a million men. Let's play that over again, too.
Who decides?
--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.
Peter Curran
I think I said that in the message you quoted.
Lawrence Kirby
...
>From _The Notebooks of Lazarus Long_, by Robert A. Heinlein:
>
> Democracy is based on the assumption that a million men are
> wiser than one man. How's that again? I missed something.
>
>Of course, the next aphorism is:
>
> Autocracy is based on the assumption that one man is
> wiser than a million men. Let's play that over again, too.
> Who decides?
This is naive in the extreme. Forms of government have little to do
with wisdom, they are to do with accountability (both actual and
perceived), representation, whose interests get served and whose
vision gets implemented, notably whether is is a very small group
of people (perhaps even just one) or a larger group.
How far this is applicable to language standards committees I'm not
entirely sure. :-)
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------