size_t in 1990 ISO C
Curtis Smith
"size_t must represent the largest unsigned type supported by the
implemenation."
I find that hard to swallow since the majority of C environments I've
worked in don't comply with that (but, then again, I don't know that
I've ever worked with a compiler that claimed full conformance with said
standard). Unfortunately, I don't have a copy of the 1990 standard to
be able verify or refute the statement myself, and I was wondering if
someone might be able to enlighten me on the issue.
Yours appreciatively,
Curtis Smith
Casper H.S. Dik - Network Security Engineer
Curtis Smith <cur...@vger.vsin.com> writes:
>I find that hard to swallow since the majority of C environments I've
>worked in don't comply with that (but, then again, I don't know that
>I've ever worked with a compiler that claimed full conformance with said
>standard). Unfortunately, I don't have a copy of the 1990 standard to
>be able verify or refute the statement myself, and I was wondering if
>someone might be able to enlighten me on the issue.
Perhaps you can give some examples of non conforming implementations?
AFAIK, implementations that have sizeof(size_t) < sizeof(uintmax_t)
have "long long" which isn't conformant anyway. (Sun's compiler's in
maximum conformant mode do not support long long annd are thus conforming
to sizeof(size_t) == sizeof(uintmax_t).
Typical 64 bit implementations are also conforming.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Thomas Pornin
> AFAIK, implementations that have sizeof(size_t) < sizeof(uintmax_t)
> have "long long" which isn't conformant anyway.
I must disagree. The ACK compiler under Minix (the 16-bit version) has a
16-bit size_t (because the total size of data cannot exceed 64 KB) and a
32-bit unsigned long. Same applies to most 16-bit Msdos-compilers, even
those which handle more than 64 KB data memory: size_t needs only to
be large enough to describe the size of the largest possible object. I
checked in Turbo C 2.01 (from Borland), it uses a 16-bit size_t.
Although those might be arguably considered as non-conforming to
ISO C90, they are pretty close nonetheless; and a fully C90 (or C99)
compliant compiler could still have a 16-bit size_t on those
architectures.
--Thomas Pornin
Jun Woong
>
>A reference I recently came across indicated that, in ISO/IEC 9899:1990,
>"size_t must represent the largest unsigned type supported by the
>implemenation."
C90 does not say so.
To the best of my knowledge, C90 allows size_t to be synonym of
"8-bit unsigned char", even if unsigned is 16 bits wide and unsigned
long is 32 bits wide in the implementation.
--
Jun Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul
Marcin 'Qrczak' Kowalczyk
> AFAIK, implementations that have sizeof(size_t) < sizeof(uintmax_t)
> have "long long" which isn't conformant anyway.
I think that old MS-DOS compilers have sizeof(size_t) == 2,
sizeof(long) == 4. But I'm not sure.
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Jun Woong
>
>I must disagree. The ACK compiler under Minix (the 16-bit version) has a
>16-bit size_t (because the total size of data cannot exceed 64 KB) and a
>32-bit unsigned long. Same applies to most 16-bit Msdos-compilers, even
>those which handle more than 64 KB data memory: size_t needs only to
>be large enough to describe the size of the largest possible object.
Where does C90 say that?
size_t is the result type of the sizeof operator.
C90 6.3.3.4 (The sizeof operator):
"The value of the result is implementation-defined, and its type (an
unsigned integral type) is size_t defined in the <stddef.h> header."
Of course, C90 requires that the resulting value of sizeof(char) is 1
and that size_t is a synonym of one of the standard unsigned integral
types (i.e. unsigned char, unsigned int and unsigned long).
Jun Woong
>
>In article <9crlr4$2g1n$1...@nef.ens.fr>, Thomas Pornin says...
>>
>>I must disagree. The ACK compiler under Minix (the 16-bit version) has a
>>16-bit size_t (because the total size of data cannot exceed 64 KB) and a
>>32-bit unsigned long. Same applies to most 16-bit Msdos-compilers, even
>>those which handle more than 64 KB data memory: size_t needs only to
>>be large enough to describe the size of the largest possible object.
>
"size_t needs only to be large ..."
Sorry. I agree with "need", but I'd disagree if it were "size_t has
to be large ...".
[...]
Douglas A. Gwyn
> To the best of my knowledge, C90 allows size_t to be synonym of
> "8-bit unsigned char", even if unsigned is 16 bits wide and unsigned
> long is 32 bits wide in the implementation.
size_t has to be some supported unsigned integer type,
and it has to be able to represent the size of any data object.
The Environmental Limits section implies (for C99) that some
data objects can require 16 bits to express their size, so
size_t always has at least 16 bits (more on most platforms).
It is certainly *not* the case that the largest (or widest)
unsigned integer type must have the same size (or width) as
size_t. C99 introduces a typedef for the widest unsigned
integer type via <stdint.h>, namely uintmax_t.
Nick Maclaren
In article <3AF1796A...@null.net>,
"Douglas A. Gwyn" <DAG...@null.net> writes:
|>
|> It is certainly *not* the case that the largest (or widest)
|> unsigned integer type must have the same size (or width) as
|> size_t. C99 introduces a typedef for the widest unsigned
|> integer type via <stdint.h>, namely uintmax_t.
No, it didn't introduce one - there was already one in C90 - it
changed it from unsigned long to uintmax_t.
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
Jun Woong
>
>Jun Woong wrote:
>> To the best of my knowledge, C90 allows size_t to be synonym of
>> "8-bit unsigned char", even if unsigned is 16 bits wide and unsigned
>> long is 32 bits wide in the implementation.
>
>size_t has to be some supported unsigned integer type,
>and it has to be able to represent the size of any data object.
>The Environmental Limits section implies (for C99) that some
>data objects can require 16 bits to express their size, so
>size_t always has at least 16 bits (more on most platforms).
>
The Environmental Limits section of C90 does NOT require size_t to
be able to represent the size of the data object. Even if a data
object whose size is 65,536 bytes is allowed in an implementation,
the implementation need not have width of size_t more than 16 bits,
as long as it documents the resulting value of sizeof of such objects.
Again, C90 6.3.3.4 (The sizeof operator):
"The value of the result is implementation-defined, and its type (an
unsigned integral type) is size_t defined in the <stddef.h> header."
Jun Woong
>> To the best of my knowledge, C90 allows size_t to be synonym of
>> "8-bit unsigned char", even if unsigned is 16 bits wide and unsigned
>> long is 32 bits wide in the implementation.
>
>size_t has to be some supported unsigned integer type,
>and it has to be able to represent the size of any data object.
>The Environmental Limits section implies (for C99) that some
>data objects can require 16 bits to express their size, so
>size_t always has at least 16 bits (more on most platforms).
>
Is there any other part of the Standard (C90 or C99) which implies
that size_t must be able to represent the size of every data object
allowed in the implementation?
If size_t is unsigned char (8 bits wide) and the implementation allows
a 32,768-bytes object, it'd be certainly unreasonable, but I don't
think it is not conforming (at least to C90).
Douglas A. Gwyn
> |> integer type via <stdint.h>, namely uintmax_t.
> No, it didn't introduce one - there was already one in C90 - it
> changed it from unsigned long to uintmax_t.
Nope, several C90 implementations have wider integer types
than unsigned long, but there was no standard way to get
at them. C99 does introduce a standard way.
I think you're thinking about the *other* C99 addition,
requiring support for (unsigned|signed) long long int.
That isn't the same issue.
Douglas A. Gwyn
> be able to represent the size of the data object.
No, you have to read the whole standard.
Nick Maclaren
I am afraid that it is.
C90 stated that there were precisely four integer types, of which
(unsigned) long was the longest, and that all standard C types must
map to one of them. A conforming implementation could add extra
types, but (a) they would not be integer types within the meaning
defined in the standard and (b) they could not be used for any
standard types.
C99 states that there are an arbitrary number, of which (u)intmax_t
is the longest, and that all standard C types must map to one of them.
A conforming implementation can add types longer than (u)intmax_t,
but (a) they would not be integer types within the meaning defined
in the standard and (b) they cannot be used for any standard types.
So where is the fundamental difference?
Curtis Smith
> Curtis Smith <cur...@vger.vsin.com> writes:
>> I find that hard to swallow since the majority of C environments
>> I've worked in don't comply with that [the assertion that size_t
>> must be size of largest supported unsigned integer type in
>> ISO/IEC 9899:1990, according to
>> http://www.unix-systems.org/whitepapers/64bit.html ] (but, then
>> again, I don't know that I've ever worked with a
>> compiler that claimed full conformance with said standard).
>> Unfortunately, I don't have a copy of the 1990 standard to be
>> able verify or refute the statement myself, and I was wondering if
>> someone might be able to enlighten me on the issue.
>
>
> Perhaps you can give some examples of non conforming implementations?
Well, I first used C on a Harris 800 which had
sizeof(char)=1 [8 bits]
sizeof(short)=sizeof(int)=sizeof(size_t)=3 [24 bits]
sizeof(unsigned long)=6 [48 bits]
And in my many years of DOS programming, I'd use
sizeof(char)=1 [8 bits]
sizeof(short)=sizeof(int)=sizeof(size_t)=2 [16 bits]
sizeof(unsigned long)=4 [32 bits]
Many others. As a matter of fact, I can't think of a single
compiler where sizeof(size_t) is the size of the largest
unsigned integer; I can think of some where sizeof(size_t)
is sizeof(unsigned long), but they all integer types longer
than unsigned long.
>
> AFAIK, implementations that have sizeof(size_t) < sizeof(uintmax_t)
> have "long long" which isn't conformant anyway. (Sun's compiler's in
> maximum conformant mode do not support long long annd are thus conforming
> to sizeof(size_t) == sizeof(uintmax_t).
Is uintmax_t in C90? My understanding that "unsigned long" was the
longest unsigned type in C90 -- that's why all implementations that
want to support both C90 and C99 have to make long, long long, and
uintmax_t all the same size (at least 64 bits).
Dan Pop
>Casper H.S. Dik - Network Security Engineer wrote:
>
> > Curtis Smith <cur...@vger.vsin.com> writes:
> >> I find that hard to swallow since the majority of C environments
> >> I've worked in don't comply with that [the assertion that size_t
> >> must be size of largest supported unsigned integer type in
> >> ISO/IEC 9899:1990, according to
> >> http://www.unix-systems.org/whitepapers/64bit.html ] (but, then
> >> again, I don't know that I've ever worked with a
> >> compiler that claimed full conformance with said standard).
> >> Unfortunately, I don't have a copy of the 1990 standard to be
> >> able verify or refute the statement myself, and I was wondering if
> >> someone might be able to enlighten me on the issue.
> >
> >
> > Perhaps you can give some examples of non conforming implementations?
>
>Well, I first used C on a Harris 800 which had
> sizeof(char)=1 [8 bits]
> sizeof(short)=sizeof(int)=sizeof(size_t)=3 [24 bits]
> sizeof(unsigned long)=6 [48 bits]
>
>And in my many years of DOS programming, I'd use
> sizeof(char)=1 [8 bits]
> sizeof(short)=sizeof(int)=sizeof(size_t)=2 [16 bits]
> sizeof(unsigned long)=4 [32 bits]
What's non conforming in these examples?
>Many others. As a matter of fact, I can't think of a single
>compiler where sizeof(size_t) is the size of the largest
>unsigned integer; I can think of some where sizeof(size_t)
>is sizeof(unsigned long), but they all integer types longer
>than unsigned long.
Then, you haven't used 64-bit systems, where size_t is typically
unsigned long and the compilers don't support longer types.
BTW, as far as the C90 standard is concerned, unsigned long is the
longest unsigned integer type. The C90 implementation may add longer
types (provided their names are in the implementation name space), but it
cannot use them for standard typedef'ed types like size_t or ptrdiff_t.
> > AFAIK, implementations that have sizeof(size_t) < sizeof(uintmax_t)
> > have "long long" which isn't conformant anyway. (Sun's compiler's in
> > maximum conformant mode do not support long long annd are thus conforming
> > to sizeof(size_t) == sizeof(uintmax_t).
>
>Is uintmax_t in C90?
No.
>My understanding that "unsigned long" was the
>longest unsigned type in C90 -- that's why all implementations that
>want to support both C90 and C99 have to make long, long long, and
>uintmax_t all the same size (at least 64 bits).
You can't support both C90 and C99 in the same implementation. long long
is a syntax error in C90 and a valid type in C99.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Douglas A. Gwyn
> Is uintmax_t in C90? My understanding that "unsigned long" was the
> longest unsigned type in C90 -- that's why all implementations that
> want to support both C90 and C99 have to make long, long long, and
> uintmax_t all the same size (at least 64 bits).
I hope no C99 implementor thinks that. In C90, "unsigned long" was
indeed the widest *standard* integer type. In C90, although many
implementations provided non-standard integer types for various
reasons, they were outside the scope of the standard; any program
using those extensions was not strictly conforming. Clearly,
long long int in C99 acts the same as an extension to C90, but in
C99 it is one of the standard integer types. (Same for _Bool.)
Implementations can still provide non-standard integer types; in
C99 we decided that it was best to identify this fact so we could
make use of it in the <inttypes.h> specification.
In C90, it was clear (and confirmed by a DR response) that all the
specified typedef names for integer types in the standard headers
had to be names for *standard* integer types, which was constraining.
In C99, this constraint has been removed, and they can be names for
either standard or extended integer types.
Douglas A. Gwyn
> So where is the fundamental difference?
The difference is that in C99 "integer type" subsumes "extended
integer type", which has a definition, whereas in C90 it didn't.
James Kuyper Jr.
So in other words, the only fundamental difference in meaning is one
that can't even be described in terms that were defined under the C90
standard? If that were the only difference, I'd say Nick is completely
correct in identifying uintmax_t as the successor to 'unsigned long'. In
particular, C90's unsigned long and C99's uintmax_t both share the key
property that's the subject of this thread: in their respective versions
of the standard, they are both the largest unsigned type. The original
poster was correct is his skepticism of a claim that that size_t shared
that property.
However, I'd say that there is another fundamental difference between
'unsigned long' in C90 and uintmax_t in C99. The former is a built-in
type, whereas the latter must be defined in <stdint.h>; it may be a
typedef for a built-in type, but it isn't itself a built-in type. This
is actually technically relevant: you said that "C99 introduces a
typedef", and Nick said "there was already one in C90". I knew what he
meant, but technically that was incorrect.
Douglas A. Gwyn
> ... C90's unsigned long and C99's uintmax_t both share the key
> property that's the subject of this thread: in their respective
> versions of the standard, they are both the largest unsigned type.
No; I already explained this, go back and read it more carefully.
James Kuyper Jr.
You've don't have to make me understand your argument, but if you're
going to even bother trying, there's no point in simply pointing me at
your previous statements. I read them as carefully as I knew how, before
posting that message.
If there was a type that was larger than unsigned long in C90, it
couldn't qualify as an integer type within the meaning of the C90
standard. If there's a type larger than uintmax_t in C99, it can't
qualify as an integer type within the meaning of the C99 standard. The
definition of integer type changed between the two standards, and the
name of the largest unsigned integer type changed, but the fact that
there was a standard-defined type that was the largest unsigned integer
type did not change.
It's precisely that fact which is relevant to this thread; size_t could
not be larger than the unsigned long in C90, because it couldn't be an
extended type. size_t can't be larger than uintmax_t in C99, because
while size_t can now be an extended type, uintmax_t includes extended
types in its definition. There's no other types which can be used to
place a tighter restriction on size_t, in either version of the
language. However, as the original poster suspected, there's no
requirement that size_t be the same size as the largest unsigned integer
type, in either version of the language.
Mr Veli Suorsa
Douglas A. Gwyn wrote:
> > ... Limits section of C90 does NOT require size_t to
> > be able to represent the size of the data object.
>
> No, you have to read the whole standard.
I fully agree with you.
Where can I read / find all these ISO, ANSI ... C90, C99 standards? Or
can you send to me a list of commands.
I need some documentations to converter project concerning about C / C++
headers/units, functions/procedures, libraries and operators.
Thanks in advance
--
Veli Suorsa
---
"People must believe to the future to be able to live!"
---------------------------------- J.V.Snellman, 1890.
Oulu, FINLAND
Mailto:VJSu...@Surfeu.Fi
http://members.surfeu.fi/veli.suorsa/
Keith Thompson
[...]
> Where can I read / find all these ISO, ANSI ... C90, C99 standards?
In the US, the C90 standard is difficult to find these days. (Herbert
Schildt's book, "The Annotated ANSI C Standard", contains almost all
of the C90 standard on the left-hand pages; the right-hand pages
contain Schildt's dangerously nonsensical annotations. The book is
out of print, but you may be able to find a copy. See
<http://www.lysator.liu.se/c/schildt.html>.)
ANSI, the American National Standards Institute, sells the C99 and C++
standards in PDF format for $18, and in hard copy for much more. You
might be able to buy it from them; if not, try Global Engineering
Documents or your national standards body.
ISO : <http://www.iso.ch>
ANSI : <http://www.ansi.org>
Global Engineering Documents : <http://global.ihs.com/>
SFS (Finland) : <http://www.sfs.fi/>
I think the C FAQ, <http://www.eskimo.com/~scs/C-faq/top.html>, has
more information, but I can't access it at the moment.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.
Mr Veli Suorsa
Keith Thompson wrote:
> of the C90 standard on the left-hand pages; the right-hand pages
> contain Schildt's dangerously nonsensical annotations. The book is
> out of print, but you may be able to find a copy. See
> <http://www.lysator.liu.se/c/schildt.html>.)
Doesn't connected...
I will try later.
> ISO : <http://www.iso.ch>
> ANSI : <http://www.ansi.org>
> Global Engineering Documents : <http://global.ihs.com/>
> SFS (Finland) : <http://www.sfs.fi/>
>
> I think the C FAQ, <http://www.eskimo.com/~scs/C-faq/top.html>, has
> more information, but I can't access it at the moment.
Every other link works, thanks.
> --
> Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
> Cxiuj via bazo apartenas ni.
Thank you, Keith and have a good Dinner
(borrowed from your homepage: will write code for food ;-)
Douglas A. Gwyn
> ... The definition of integer type changed between the two standards,
Yes, so you're comparing apples and oranges.
> It's precisely that fact which is relevant to this thread; size_t could
> not be larger than the unsigned long in C90, because it couldn't be an
> extended type. size_t can't be larger than uintmax_t in C99, because
> while size_t can now be an extended type, uintmax_t includes extended
> types in its definition.
However, size_t can be wider than unsigned long long int.
The claim which I was disputing was that C99 implementations that
wanted to be compatible with C89 implementations on the same
platform would have to make long int, long long int, and intmax_t
all the same size. Somehow that was supposed to follow from the
(mistaken) notion that size_t had to be the widest type in C89.
Even if the mistaken notion had been true, the conclusion would
not have followed.
Nick Maclaren
No, the notion is mistaken, but the conclusion is correct. There
are two points here:
1) Unless all standard types (including size_t) are no longer
than long, certain conforming and perfectly portable programs in
C90 become undefined in C99.
2) Unless intmax_t (and hence long long) is no longer than long,
certain C90 programs that would have violated a constraint error
no longer do so.
James Kuyper
>
> "James Kuyper Jr." wrote:
> > ... The definition of integer type changed between the two standards,
>
> Yes, so you're comparing apples and oranges.
>
> > It's precisely that fact which is relevant to this thread; size_t could
> > not be larger than the unsigned long in C90, because it couldn't be an
> > extended type. size_t can't be larger than uintmax_t in C99, because
> > while size_t can now be an extended type, uintmax_t includes extended
> > types in its definition.
>
> However, size_t can be wider than unsigned long long int.
Agreed, though not in a C90 implementation, of course.
> The claim which I was disputing was that C99 implementations that
> wanted to be compatible with C89 implementations on the same
> platform would have to make long int, long long int, and intmax_t
> all the same size. Somehow that was supposed to follow from the
That claim was not being made in the messages you were responding to.
> (mistaken) notion that size_t had to be the widest type in C89.
> Even if the mistaken notion had been true, the conclusion would
> not have followed.
True. But I don't think that the mistaken notion was restricted to C89;
I think it was also being assumed to apply to C99 (I can't verify that,
since the relevant message has expired on my newsserver). If compability
means that types with the same name in both implemenations have the same
size, alignment, and representation, then the mistaken belief that BOTH
versions of the standard require size_t to be the largest unsigned
integer type would have justified that conclusion.
Clive D. W. Feather
<kuy...@wizard.net> writes
>If that were the only difference, I'd say Nick is completely
>correct in identifying uintmax_t as the successor to 'unsigned long'. In
>particular, C90's unsigned long and C99's uintmax_t both share the key
>property that's the subject of this thread: in their respective versions
>of the standard, they are both the largest unsigned type.
Nick is correct. We added uintmax_t to C99 precisely to prevent this
problem coming up with long long long in C2010, and I and others fought
hard to make it mandatory (it was optional in earlier drafts, which had
some interesting implications for preprocessor arithmetic).
>The original
>poster was correct is his skepticism of a claim that that size_t shared
>that property.
Also correct; in C90 size_t could be any of the four unsigned integer
types.
>However, I'd say that there is another fundamental difference between
>'unsigned long' in C90 and uintmax_t in C99. The former is a built-in
>type, whereas the latter must be defined in <stdint.h>; it may be a
>typedef for a built-in type, but it isn't itself a built-in type.
Typedefs are another way of writing the type's name; they don't of
themselves introduce new types.
In particular, consider the following:
typedef int fred;
struct
{
fred x; // guaranteed signed
fred y : 2; // might be unsigned
};
--
Clive D.W. Feather, writing for himself | Home: <cl...@davros.org>
Tel: +44 20 8371 1138 (work) | Web: <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax) | Work: <cl...@demon.net>
Written on my laptop; please observe the Reply-To address
Clive D. W. Feather
<myco...@hanmail.net> writes
>Is there any other part of the Standard (C90 or C99) which implies
>that size_t must be able to represent the size of every data object
>allowed in the implementation?
The exact wording in C99 is:
[#2] The sizeof operator yields the size (in bytes) of its
operand, which may be an expression or the parenthesized
name of a type. The size is determined from the type of the
operand.
[#4] The value of the result is implementation-defined, and
its type (an unsigned integer type) is size_t, defined in
<stddef.h> (and other headers).
Note that #2 does not say "the size, converted to the type size_t", just
"the size". The "implementation-defined" bit in #4 is a red herring; it
does not grant licence to ignore #2.
During the C99 process I asked for a constraint to be added requiring
the size of the operand to be no greater than SIZE_MAX. This was refused
on the grounds that it's unnecessary.
James Kuyper Jr.
>
> In article <3AF3E51A...@wizard.net>, James Kuyper Jr.
> <kuy...@wizard.net> writes
> >However, I'd say that there is another fundamental difference between
> >'unsigned long' in C90 and uintmax_t in C99. The former is a built-in
> >type, whereas the latter must be defined in <stdint.h>; it may be a
> >typedef for a built-in type, but it isn't itself a built-in type.
>
> Typedefs are another way of writing the type's name; they don't of
> themselves introduce new types.
Correct; I should have said that uintmax_t was not itself the name of a
built-in type.