473,394 Members | 1,746 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,394 software developers and data experts.

size_t - why?

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.

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.

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).

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.

Nov 23 '05 #1
18 2142
"rayw" <ra*********@gmail.com> wrote:
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.
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.
However, it seems as though size_t is *usually* an unsigned long - so prop.1
can't be right


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
Nov 23 '05 #2
rayw wrote:
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,
No, though this is very common. A char is CHAR_BIT bits, where CHAR_BIT= 8. a int >= a char
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.
a long >= int
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.
etc
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>.
Meaning that a compiler might only provide 8 bit longs, and still be
compliant.
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).
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.
To be precise, size_t is the type used by sizeof. Informally, size_t is
the type we can use to count bytes.
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).
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.
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.

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.
Nov 23 '05 #3

"Skarmander" <in*****@dontmailme.com> wrote in message
news:43***********************@news.xs4all.nl...
rayw wrote:
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,

No, though this is very common. A char is CHAR_BIT bits, where CHAR_BIT
= 8.

a int >= a char

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.
a long >= int

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.
etc

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>.
Meaning that a compiler might only provide 8 bit longs, and still be
compliant.

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).
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.

To be precise, size_t is the type used by sizeof. Informally, size_t is
the type we can use to count bytes.
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).

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

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.


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.
Nov 23 '05 #4
rayw wrote:
<snip>
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.

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.
Nov 23 '05 #5
Skarmander wrote:
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).


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.
Nov 23 '05 #6
On 2005-11-22, Skarmander <in*****@dontmailme.com> wrote:
rayw wrote:
a long >= int
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.


thus the = in ">="
sizeof(long)*CHAR_BIT >= sizeof(int)*CHAR_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
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).

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.


A common name for such platforms is ILP32
On such platforms "unsigned long" is the natural choice for size_t.


There are also standards [not the C standard itself, but others which
build on it] which require sizeof(size_t) <= sizeof(long)
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.

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.


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]
Nov 23 '05 #7
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.

Nov 23 '05 #8
CoffeeGood wrote:
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.

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.
Nov 23 '05 #9
CoffeeGood said:
Just a comment, CHAR_BIT is not defined by gcc
#include <limits.h>
and setting it with
-DCHAR_BIT=16
has no effect on the size of a char.


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)
Nov 23 '05 #10
CoffeeGood wrote
(in article
<11**********************@f14g2000cwb.googlegroups .com>):
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.


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

Nov 23 '05 #11
>CHAR_BIT is descriptive.

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

Nov 23 '05 #12
CoffeeGood wrote:
CHAR_BIT is descriptive.


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


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
Nov 23 '05 #13
CoffeeGood said:
CHAR_BIT is descriptive.
Right. That's what I was saying.


No, it wasn't.
Your point is?


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)
Nov 23 '05 #14

"CoffeeGood" <fb***@yahoo.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
CHAR_BIT is descriptive.


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


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.

Nov 23 '05 #15
>Just beyond your grasp.

What's beyond your grasp is that you use Usenet
to insult people in order to feel better about
yourself because you have low self-esteem.

Nov 23 '05 #16
CoffeeGood wrote
(in article
<11*********************@g14g2000cwa.googlegroups. com>):
Just beyond your grasp.


What's beyond your grasp is that you use Usenet
to insult people in order to feel better about
yourself because you have low self-esteem.


Once again (after being asked not to) you have nuked the
attributions, but you are referring to Richard Heathfield above.
He is one of the most respected "regulars" in the group, and
does not insult people typically, in fact he is often the one
asking others to calm down.

It is not insulting for people (typically) asking for help to
find out that the reason they need help is that they don't
understand it fully yet. In fact, if that were not the case,
they wouldn't be needing help at all.

He probably objected to what looks on paper to be a lie, namely
you claiming that you had felt that CHAR_BIT was descriptive in
a response to his, after you had pretty adequately demonstrated
the opposite position, by trying to set CHAR_BIT with a
-DCHAR_BIT directive to your compiler. Most people get a bit
snippy when lied to.

Perhaps I misunderstood, and you can explain to me and the rest
of the readers of this thread how those posts should be
interpreted differently.

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

Nov 23 '05 #17
rayw <ra*********@gmail.com> wrote:

"CoffeeGood" <fb***@yahoo.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
>CHAR_BIT is descriptive.
Right. That's what I was saying. Your point is?


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]


Actually it means UINT is at least 32 bits but could be bigger even
though the alloweable maximum value is 0xffffffff.
On a binary computer one can get the number of bits of an unsigned int by
CHAR_BIT*sizeof(unsigned int).

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.


--
Z (zo**********@web.de)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Nov 25 '05 #18
Zoran Cutura <zo**********@web.de> writes:
rayw <ra*********@gmail.com> wrote:
"CoffeeGood" <fb***@yahoo.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
>CHAR_BIT is descriptive.

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


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]


Actually it means UINT is at least 32 bits but could be bigger even
though the alloweable maximum value is 0xffffffff.
On a binary computer one can get the number of bits of an unsigned int by
CHAR_BIT*sizeof(unsigned int).


And on a non-binary computer, one can't have a conforming C
implementation (unless it emulates binary on top of whatever the
hardware uses). Your statement is equally true without the "On a
binary computer" qualification.

--
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.
Nov 25 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: javadesigner | last post by:
Hi: I am a bit new to C programming and am trying to write a wrapper around malloc. Since malloc takes size_t as it's parameter, I want to be able to see if my function recieved an argument...
5
by: edware | last post by:
Hello, I have some questions about the size_t type. First, what do we know about size_t? From what I have read I believe that it is an unsigned integer, but not necessarily an int. Am I correct?...
12
by: Alex Vinokur | last post by:
Why was the size_t type defined in compilers in addition to unsigned int/long? When/why should one use size_t? Alex Vinokur email: alex DOT vinokur AT gmail DOT com...
39
by: Mark Odell | last post by:
I've always declared variables used as indexes into arrays to be of type 'size_t'. I have had it brought to my attention, recently, that size_t is used to indicate "a count of bytes" and that using...
23
by: bwaichu | last post by:
To avoid padding in structures, where is the best place to put size_t variables? According the faq question 2.12 (http://c-faq.com/struct/padding.html), it says: "If you're worried about...
318
by: jacob navia | last post by:
Rcently I posted code in this group, to help a user that asked to know how he could find out the size of a block allocated with malloc. As always when I post something, the same group of people...
73
by: Yevgen Muntyan | last post by:
Hey, I was reading C99 Rationale, and it has the following two QUIET CHANGE paragraphs: 6.5.3.4: "With the introduction of the long long and extended integer types, the sizeof operator may...
89
by: Tubular Technician | last post by:
Hello, World! Reading this group for some time I came to the conclusion that people here are split into several fractions regarding size_t, including, but not limited to, * size_t is the...
27
by: mike3 | last post by:
Hi. I can't believe I may have to use an array here. I've got this bignum package I was making in C++ for a fractal generator, and tried an approach that was suggested to me here a while...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.