regarding size_t

[sam_cit]

Hi Everyone,

I was looking at the function prototype of malloc() function in
stdlib.h and i found that to be,

void *malloc(size_t size);

so what is size_t is it a pre-defined typedef to int?

Thanks in advance.

 

[jaysome]

Hi Everyone,

I was looking at the function prototype of malloc() function in
stdlib.h and i found that to be,

void *malloc(size_t size);

so what is size_t is it a pre-defined typedef to int?

Thanks in advance.

size_t is a pre-defined type, which, according to the C Standard, is
"the unsigned integral type of the result of the sizeof operator". The
type size_t is unsigned, and it cannot possibly be defined as type
int, which must be signed.

 

[Guest]

Hi Everyone,

I was looking at the function prototype of malloc() function in
stdlib.h and i found that to be,

void *malloc(size_t size);

so what is size_t is it a pre-defined typedef to int?

size_t is a typedef for some unsigned integer type meant to be capable
of storing the size of objects. It is not pre-defined: it is defined in
several of the standard headers, but if you don't include any of them,
you're free to use size_t as an ordinary identifier in your own code.
Which specific type it has depends on the implementation, and it would
be best not to assume anything more than you need to about it.

 

[CBFalconer]

size_t is a typedef for some unsigned integer type meant to be
capable of storing the size of objects. It is not pre-defined: it
is defined in several of the standard headers, but if you don't
include any of them, you're free to use size_t as an ordinary
identifier in your own code. Which specific type it has depends
on the implementation, and it would be best not to assume
anything more than you need to about it.

No, you are not free to use it for other purposes. You MAY get
away with it on some implementations. You are not free to use
anything defined in any standard headers.

 

[Guest]

No, you are not free to use it for other purposes. You MAY get
away with it on some implementations. You are not free to use
anything defined in any standard headers.

Citation, please?

 

[Eric Sosman]

size_t is a pre-defined type, which, according to the C Standard, is
"the unsigned integral type of the result of the sizeof operator". The
type size_t is unsigned, and it cannot possibly be defined as type
int, which must be signed.

A minor clarification: size_t is "pre-defined" if you include
one or more of the headers that define it, but is not "baked in"
to the compiler in the way sizeof is. The following is a legal C
function, albeit a stupid one:

#include <math.h>
double size_t(double FILE, double NULL, double offsetof) {
return (-NULL + sqrt(NULL*NULL - 4*FILE*offsetof))
/ (2*FILE);
}

The following translation unit is not legal C:

/* no header inclusions */
size_t elementCount(size_t arraySize, size_t elementSize) {
return arraySize / elementSize;
}

.... because size_t is not defined.

 

[CBFalconer]

Citation, please?

From N869:

7.1.3 Reserved identifiers

[#1] Each header declares or defines all identifiers listed
in its associated subclause, and optionally declares or
defines identifiers listed in its associated future library
directions subclause and identifiers which are always
reserved either for any use or for use as file scope
identifiers.

-- All identifiers that begin with an underscore and
either an uppercase letter or another underscore are
always reserved for any use.

-- All identifiers that begin with an underscore are
always reserved for use as identifiers with file scope
in both the ordinary and tag name spaces.

-- Each macro name in any of the following subclauses
(including the future library directions) is reserved
for use as specified if any of its associated headers
is included; unless explicitly stated otherwise (see
7.1.4).

-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.143)

____________________

143The list of reserved identifiers with external linkage
includes errno, setjmp, and va_end.

 

[Martin Ambuhl]

Hi Everyone,

I was looking at the function prototype of malloc() function in
stdlib.h and i found that to be,

void *malloc(size_t size);

so what is size_t is it a pre-defined typedef to int?

It can't be. 'int' is a signed integer type; 'size_t' is an unsigned
integer type.

 

[Guest]

7.1.3 Reserved identifiers

7.1.3 applies, but the part that applies is what follows the list of
cases: "No other identifiers are reserved." size_t does not start with
an underscore, its header is not included, and the standard definition
of it has no linkage, so none of the cases that say identifiers are
reserved apply. (You missed one, by the way.)

 

[Guest]

Citation, please?

From N869:

7.1.3 Reserved identifiers

[#1] Each header declares or defines all identifiers listed
in its associated subclause, and optionally declares or
defines identifiers listed in its associated future library
directions subclause and identifiers which are always
reserved either for any use or for use as file scope
identifiers.

-- All identifiers that begin with an underscore and
either an uppercase letter or another underscore are
always reserved for any use.

-- All identifiers that begin with an underscore are
always reserved for use as identifiers with file scope
in both the ordinary and tag name spaces.

-- Each macro name in any of the following subclauses
(including the future library directions) is reserved
for use as specified if any of its associated headers
is included; unless explicitly stated otherwise (see
7.1.4).

-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.143)

____________________

143The list of reserved identifiers with external linkage
includes errno, setjmp, and va_end.

You left out

-- Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved
for use as a macro name and as an identifier with file scope in
the same name space if any of its associated headers is included.

So which case applies to an identifier that does not start with _, does
not have its header included, and the standard definition of which has
no linkage? (My apologies if I reply to your message more than once;
I'm having some problems.)

 

[Keith Thompson]

Citation, please?

From N869:

7.1.3 Reserved identifiers

[#1] Each header declares or defines all identifiers listed
in its associated subclause, and optionally declares or
defines identifiers listed in its associated future library
directions subclause and identifiers which are always
reserved either for any use or for use as file scope
identifiers.

So <stddef.h> and a couple of other headers declare size_t. Based
only on what we've seen so far, if I don't include a header that
declares size_t, I can declare it myself.

-- All identifiers that begin with an underscore and
either an uppercase letter or another underscore are
always reserved for any use.

This doesn't apply to size_t (its name doesn't begin with an
underscore).

-- All identifiers that begin with an underscore are
always reserved for use as identifiers with file scope
in both the ordinary and tag name spaces.

This doesn't apply to size_t (its name doesn't begin with an
underscore).

-- Each macro name in any of the following subclauses
(including the future library directions) is reserved
for use as specified if any of its associated headers
is included; unless explicitly stated otherwise (see
7.1.4).

This doesn't apply to size_t (it's not a macro name).

-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.143)

This doesn't apply to size_t. Only identifiers that denote objects or
functions have linkage; typedef names do not.

 

[Keith Thompson]

I was looking at the function prototype of malloc() function in
stdlib.h and i found that to be,

void *malloc(size_t size);

so what is size_t is it a pre-defined typedef to int?

This is the kind of question that can be answered by looking up
"size_t" in any decent C reference. Do you have one? Even if you
don't, you can download a free copy of a draft of the C standard; it's
not easy reading, but it's the definitive reference.

 

[David T. Ashley]

Hi Everyone,

I was looking at the function prototype of malloc() function in
stdlib.h and i found that to be,

void *malloc(size_t size);

so what is size_t is it a pre-defined typedef to int?

Thanks in advance.

In the good old days of 'C' when integers were 32 bits and 2^32 was more
memory (and probably disk space) than any machine could ever hope to have,
the model of having everything be an integer was fine.

But, over the years, trouble crept in. Specifically, machines might now
have more memory than the most convenient size of integer for the
architecture.

And so, the need for size_t.

Things were simpler when everything was an integer and type definitions were
fast and loose. We should move immediately to 256-bit integers and that
should keep everything simple for a hundred years or so.

 

[Malcolm McLean]

Things were simpler when everything was an integer and type definitions
were fast and loose. We should move immediately to 256-bit integers and
that should keep everything simple for a hundred years or so.

Problem is that committees react to changes by proliferating the number of
language constructs. It always easier to add than to remove, with the result
that the standard steadily deteriorates.
64-bits will hold an address space for many years to come. int should be 64
bits. Then practically everything can just use ints and be done with it.
If the machine has a 64-bit adress bus, the amount of memory used by an
integer is unlikely to be a problem, except maybe in one or two big arrays.
So the memory-conscious can use bitfields in the normal case when those
records are structures. short will be either 16 or 32 bits in the rare cases
that you need a shorter integer.

It does of course inconvenience a very few people who want both 32 bit and
16 bit integers. Compilers can easily provide platform-specific options. So
we are left with a few people who need to write portable code and need fixed
integer sizes and can't use bitfields. No change is ever perfect. Removal of
long / long long types and size_t from the vast majority of code is a big
enough benefit to outweigh the problems this small group will face.