size_t - why?

**Richard Bos** · Nov 23 '05, 04:08 AM

Re: size_t - why?

"rayw" <ray.webster@gm ail.com> wrote:
[color=blue]
> I used to believe that size_t was something to do with integral types, and
> the std.
>
> Something along the lines of ..
>
> a char is 8 bits,
>
> a int >= a char
>
> a long >= int
>
> etc
>
> Meaning that a compiler might only provide 8 bit longs, and still be
> compliant.[/color]

No. A long must be larger than or equal to an int, but it must also be
at least 32 bits. This means that it's legal for all of char, int and
long to have the same size, and sizeof (long) == sizeof (int) == sizeof
(char) == 1, but then CHAR_BIT must be at least 32.
[color=blue]
> However, it seems as though size_t is *usually* an unsigned long - so prop.1
> can't be right[/color]

That's not the right inference, though. _Usually_ an unsigned long is
larger than a char. It's true that your first property is incorrect, but
it doesn't follow from the definition of size_t on any given platform.

Richard

**Skarmander** · Nov 23 '05, 04:08 AM

Re: size_t - why?

rayw wrote:[color=blue]
> I used to believe that size_t was something to do with integral types, and
> the std.
>
> Something along the lines of ..
>
> a char is 8 bits,
>[/color]
No, though this is very common. A char is CHAR_BIT bits, where CHAR_BIT[color=blue]
>= 8.[/color]
[color=blue]
> a int >= a char
>[/color]
Not quite. An int is at least 16 bits (the minimum value it can hold
must be -32767 or smaller, the maximum value 32767 or greater). A char
could be 16 bits too, of course.
[color=blue]
> a long >= int
>[/color]
Nope. A long is at least 32 bits. An int could be 32 bits as well, but a
long may not be 16 bits, and an int may.
[color=blue]
> etc
>[/color]
I could rehash the exact rules, but you're better off rereading them
yourself (you state below that you have a copy of the standard). Look up
<limits.h>.
[color=blue]
> Meaning that a compiler might only provide 8 bit longs, and still be
> compliant.
>[/color]
No. Longs must be at least 32 bits long. A compiler may, however,
provide chars that are 32 bits long and still be compliant (that is,
sizeof long == 1).
[color=blue]
> So, I thought size_t was something 'extra' ... 'size_t is guaranteed to have
> enough bits to be able to hold the size of some array/malloc'ed memory' etc.
>[/color]
To be precise, size_t is the type used by sizeof. Informally, size_t is
the type we can use to count bytes.
[color=blue]
> However, it seems as though size_t is *usually* an unsigned long - so prop.1
> can't be right (can someone correct that - or point me to the right bit of
> the stds please).
>[/color]
size_t is usually an unsigned long because 32-bit platforms (with 32-bit
integers, 32-bit longs and 32-bit addresses) are very common. On such
platforms "unsigned long" is the natural choice for size_t.
[color=blue]
> So, now I'm confused, and, yes, I've googled, and I can't find a rational
> for size_t. I've searched =my great value for money= copy of
> INCITS+ISO+IEC+ 9899-1999.pdf, but the adobe reader sucks in terms of its
> ability to accept search terms like 'type_t NEAR rationale' etc.
>[/color]
The reason size_t is not simply a long on all platforms is because an
arithmetic type of at least 32 bits is not necessarily a natural choice
for the type used to hold the size of an object.

In 7.17.4, the standard recommends
"The types used for size_t and ptrdiff_t should not have an integer
conversion rank greater than that of signed long int unless the
implementation supports objects large enough to make this necessary."

This explicitly acknowledges the possibility of size_t being greater
than a long (though it is recommended that this not be so unless
actually necessary, because older programs or badly written newer
programs might break if this does not hold). On the flip side, size_t
might be smaller on small platforms where single objects cannot exceed a
certain size, although memory as a whole may be larger.

size_t is left abstract so platforms are not artificially constrained.

S.

**rayw** · Nov 23 '05, 04:08 AM

Re: size_t - why?

"Skarmander " <invalid@dontma ilme.com> wrote in message
news:438309f4$0 $11062$e4fe514c @news.xs4all.nl ...[color=blue]
> rayw wrote:[color=green]
>> I used to believe that size_t was something to do with integral types,
>> and the std.
>>
>> Something along the lines of ..
>>
>> a char is 8 bits,
>>[/color]
> No, though this is very common. A char is CHAR_BIT bits, where CHAR_BIT[color=green]
> >= 8.[/color]
>[color=green]
>> a int >= a char
>>[/color]
> Not quite. An int is at least 16 bits (the minimum value it can hold must
> be -32767 or smaller, the maximum value 32767 or greater). A char could be
> 16 bits too, of course.
>[color=green]
>> a long >= int
>>[/color]
> Nope. A long is at least 32 bits. An int could be 32 bits as well, but a
> long may not be 16 bits, and an int may.
>[color=green]
>> etc
>>[/color]
> I could rehash the exact rules, but you're better off rereading them
> yourself (you state below that you have a copy of the standard). Look up
> <limits.h>.
>[color=green]
>> Meaning that a compiler might only provide 8 bit longs, and still be
>> compliant.
>>[/color]
> No. Longs must be at least 32 bits long. A compiler may, however, provide
> chars that are 32 bits long and still be compliant (that is, sizeof long
> == 1).
>[color=green]
>> So, I thought size_t was something 'extra' ... 'size_t is guaranteed to
>> have enough bits to be able to hold the size of some array/malloc'ed
>> memory' etc.
>>[/color]
> To be precise, size_t is the type used by sizeof. Informally, size_t is
> the type we can use to count bytes.
>[color=green]
>> However, it seems as though size_t is *usually* an unsigned long - so
>> prop.1 can't be right (can someone correct that - or point me to the
>> right bit of the stds please).
>>[/color]
> size_t is usually an unsigned long because 32-bit platforms (with 32-bit
> integers, 32-bit longs and 32-bit addresses) are very common. On such
> platforms "unsigned long" is the natural choice for size_t.
>[color=green]
>> So, now I'm confused, and, yes, I've googled, and I can't find a rational
>> for size_t. I've searched =my great value for money= copy of
>> INCITS+ISO+IEC+ 9899-1999.pdf, but the adobe reader sucks in terms of its
>> ability to accept search terms like 'type_t NEAR rationale' etc.
>>[/color]
> The reason size_t is not simply a long on all platforms is because an
> arithmetic type of at least 32 bits is not necessarily a natural choice
> for the type used to hold the size of an object.
>
> In 7.17.4, the standard recommends
> "The types used for size_t and ptrdiff_t should not have an integer
> conversion rank greater than that of signed long int unless the
> implementation supports objects large enough to make this necessary."
>
> This explicitly acknowledges the possibility of size_t being greater than
> a long (though it is recommended that this not be so unless actually
> necessary, because older programs or badly written newer programs might
> break if this does not hold). On the flip side, size_t might be smaller on
> small platforms where single objects cannot exceed a certain size,
> although memory as a whole may be larger.
>
> size_t is left abstract so platforms are not artificially constrained.[/color]

Thanks to both, esp. 'S'. All clear now - and thanks for the stds
reference - although to find it you must *not* be using the Adobe reader -
or maybe you've the patience of a saint.

**Skarmander** · Nov 23 '05, 04:08 AM

Re: size_t - why?

rayw wrote:
<snip>[color=blue]
> Thanks to both, esp. 'S'. All clear now - and thanks for the stds
> reference - although to find it you must *not* be using the Adobe reader -
> or maybe you've the patience of a saint.
>[/color]
I am actually using Acrobat Reader. The standard has an excellent index
(try this before anything else), and is well-organized in chapters.
(Also, having looked up various things, I have a feeling for where stuff
goes.)

You're right that the search function is pretty much useless in this
case, except when I recall part of the exact wording of something.

S.

**Tim Prince** · Nov 23 '05, 04:09 AM

Re: size_t - why?

Skarmander wrote:[color=blue]
> In 7.17.4, the standard recommends
> "The types used for size_t and ptrdiff_t should not have an integer
> conversion rank greater than that of signed long int unless the
> implementation supports objects large enough to make this necessary."
>
> This explicitly acknowledges the possibility of size_t being greater
> than a long (though it is recommended that this not be so unless
> actually necessary, because older programs or badly written newer
> programs might break if this does not hold).[/color]

It is "actually necessary" for implementations like 64-bit Windows,
where long was chosen as a 32-bit data type, but 40 bits may be required
to hold the size of an object. I won't argue whether the 32-bit long
makes it broken, but I can't agree with those who claim that shortening
size_t would fix it.

**Jordan Abel** · Nov 23 '05, 04:09 AM

Re: size_t - why?

On 2005-11-22, Skarmander <invalid@dontma ilme.com> wrote:[color=blue]
> rayw wrote:[color=green]
>> a long >= int
>>[/color]
> Nope. A long is at least 32 bits. An int could be 32 bits as well, but a
> long may not be 16 bits, and an int may.[/color]

thus the = in ">="
sizeof(long)*CH AR_BIT >= sizeof(int)*CHA R_BIT
/* clearly what he meant, and what you were debating anyway. */
32 >= 16
32 >= 32
64 >= 32
36 >= 18
36 >= 21
and so on.

Reading further, it does seem that he forgot the minimum size rules,
though.

for a concise representation of the rules:

8 <= char <= short <= int <= long <= long long
16 <= short
32 <= long
64 <= long long
[color=blue][color=green]
>> However, it seems as though size_t is *usually* an unsigned long - so prop.1
>> can't be right (can someone correct that - or point me to the right bit of
>> the stds please).
>>[/color]
> size_t is usually an unsigned long because 32-bit platforms (with
> 32-bit integers, 32-bit longs and 32-bit addresses) are very common.[/color]

A common name for such platforms is ILP32
[color=blue]
> On such platforms "unsigned long" is the natural choice for size_t.[/color]

There are also standards [not the C standard itself, but others which
build on it] which require sizeof(size_t) <= sizeof(long)
[color=blue][color=green]
>> So, now I'm confused, and, yes, I've googled, and I can't find a rational
>> for size_t. I've searched =my great value for money= copy of
>> INCITS+ISO+IEC+ 9899-1999.pdf, but the adobe reader sucks in terms of its
>> ability to accept search terms like 'type_t NEAR rationale' etc.
>>[/color]
> The reason size_t is not simply a long on all platforms is because an
> arithmetic type of at least 32 bits is not necessarily a natural choice
> for the type used to hold the size of an object.[/color]

For example, I believe that on PDP-11 UNIX [which was before the C
standard and size_t] it uses an unsigned int [for the result of sizeof
and the parameter to malloc, etc]

**CoffeeGood** · Nov 23 '05, 04:09 AM

Re: size_t - why?

Just a comment, CHAR_BIT is not defined by gcc and setting it with
-DCHAR_BIT=16
has no effect on the size of a char.

**Skarmander** · Nov 23 '05, 04:09 AM

Re: size_t - why?

CoffeeGood wrote:[color=blue]
> Just a comment, CHAR_BIT is not defined by gcc and setting it with
> -DCHAR_BIT=16
> has no effect on the size of a char.
>[/color]
CHAR_BIT is defined in <limits.h>.

Defining it yourself makes no sense. The size macros reflect the
platform's details; they do not configure it.

S.

**Richard Heathfield** · Nov 23 '05, 04:09 AM

Re: size_t - why?

CoffeeGood said:
[color=blue]
> Just a comment, CHAR_BIT is not defined by gcc[/color]

#include <limits.h>
[color=blue]
> and setting it with
> -DCHAR_BIT=16
> has no effect on the size of a char.[/color]

Of course not. CHAR_BIT is descriptive. It's telling you how many bits are
in a char on that platform, not inviting you to make up your own figure.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

**Randy Howard** · Nov 23 '05, 04:09 AM

Re: size_t - why?

CoffeeGood wrote
(in article
<1132675410.915 361.105170@f14g 2000cwb.googleg roups.com>):
[color=blue]
> Just a comment, CHAR_BIT is not defined by gcc and setting it with
> -DCHAR_BIT=16
> has no effect on the size of a char.[/color]

Huh? Why on earth would you think it is a tunable parameter?

Try looking in limits.h on your implementation and seeing what
it says.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

**CoffeeGood** · Nov 23 '05, 04:09 AM

Re: size_t - why?

>CHAR_BIT is descriptive.

Right. That's what I was saying. Your point is?

**pete** · Nov 23 '05, 04:09 AM

Re: size_t - why?

CoffeeGood wrote:[color=blue]
>[color=green]
> >CHAR_BIT is descriptive.[/color]
>
> Right. That's what I was saying. Your point is?[/color]

I couldn't understand what you were saying.
It seemed to me as though you were saying
that CHAR_BIT wasn't defined by the implementation.

What do you think CHAR_BIT is defined by?

--
pete

**Richard Heathfield** · Nov 23 '05, 04:09 AM

Re: size_t - why?

CoffeeGood said:
[color=blue][color=green]
>>CHAR_BIT is descriptive.[/color]
>
> Right. That's what I was saying.[/color]

No, it wasn't.
[color=blue]
> Your point is?[/color]

Just beyond your grasp.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

**rayw** · Nov 23 '05, 12:35 PM

Re: size_t - why?

"CoffeeGood " <fbui2@yahoo.co m> wrote in message
news:1132680702 .597671.90370@f 14g2000cwb.goog legroups.com...[color=blue][color=green]
> >CHAR_BIT is descriptive.[/color]
>
> Right. That's what I was saying. Your point is?
>[/color]

I think the point was that limits.h is just a file that [hopefully]
describes your compiler's limits.

My limits.h says that UINT_MAX is 0xffffffff, so a UINT is 32 bits
[according to my limits.h]

However - the compiler might be mislead, e.g., if I've somehow nuked my
include files, and that sizeof(unsigned int) is the actual truth of the
matter.

size_t - why?

size_t - why?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment