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.

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:

Harald van D?k wrote:

>CBFalconer wrote:

>>Harald van D?k wrote:
sam_...@yaho o.co.in wrote:

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.

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?

>>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.hand 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 (The_Other_Keit h) 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.

[Keith Thompson]

sa*****@yahoo.c o.in writes:

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.

--
Keith Thompson (The_Other_Keit h) 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.

[David T. Ashley]

<sa*****@yahoo. co.inwrote in message
news:11******** **************@ 51g2000cwl.goog legroups.com...

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.
------------------------------------------------------------
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Malcolm McLean]

"David T. Ashley" <dt*@e3ft.comwr ote in message

<sa*****@yahoo. co.inwrote in message
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.