Can size_t be used as a substitute to unsigned long int ?

[pereges]

For eg :

struct mesh
{
size_t nvert; /* number of vertices */
size_t ntri; /* number of triangles */
.....
};

The reason I want to use size_t is because I've read that it is
capable of supporting size of the largest possible integer in the C
implementation. In my case, the value of nvert can vary from any thing
like 30-40 to even 10 million.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Thu, 26 Jun 2008 09:58:53 -0700, pereges wrote:

For eg :

struct mesh
{
size_t nvert; /* number of vertices */
size_t ntri; /* number of triangles */
.....
};

The reason I want to use size_t is because I've read that it is capable
of supporting size of the largest possible integer in the C
implementation.

I doubt that is what you read. It's more likely that you read something
similar, and misunderstood. size_t is capable of holding the size of the
largest possible object in the C implementation, but it's not always, and
maybe not even usually, capable of holding the largest possible integer.
On my system, for example, the largest integer has a value of
18446744073709551615, but I cannot store that in a size_t, and I cannot
even come close to creating any object that large.

In my case, the value of nvert can vary from any thing
like 30-40 to even 10 million.

[pereges]

On Jun 26, 10:06 pm, Harald van D©¦k <[e-mail]:

>
I doubt that is what you read. It's more likely that you read something
similar, and misunderstood. size_t is capable of holding the size of the
largest possible object in the C implementation, but it's not always, and
maybe not even usually, capable of holding the largest possible integer.
On my system, for example, the largest integer has a value of
18446744073709551615, but I cannot store that in a size_t, and I cannot
even come close to creating any object that large.

But the value that a size_t type variable can hold must be integer ?
Then what do you mean by largest possible object ?

[Richard Tobin]

In article <a0**********************************@z24g2000prf. googlegroups.com>,
pereges <Br*****@gmail.comwrote:

For eg :

struct mesh
{
size_t nvert; /* number of vertices */
size_t ntri; /* number of triangles */
.....
};

The reason I want to use size_t is because I've read that it is
capable of supporting size of the largest possible integer in the C
implementation. In my case, the value of nvert can vary from any thing
like 30-40 to even 10 million.

size_t is appropriate for counting things that are represented as C
objects. It's not necessarily the largest (unsigned) integral type,
but it's effectively a limit on the size of arrays.

It would not be appropriate for counting things that are not
represented by C objects, such as the age of the universe or the
length of a line.

-- Richard

--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[vippstar]

On Jun 26, 7:58 pm, pereges <[e-mail]:

For eg :

struct mesh
{
size_t nvert; /* number of vertices */
size_t ntri; /* number of triangles */
.....

};

The reason I want to use size_t is because I've read that it is
capable of supporting size of the largest possible integer in the C
implementation. In my case, the value of nvert can vary from any thing
like 30-40 to even 10 million.

If you want the largest unsigned integer supported by your
implementation, use uintmax_t (<stdint.h>).
SIZE_MAX (in <limits.h>) is at least 65535.
ULONG_MAX (in <limits.h>) is at least 4294967295.

It's possible that SIZE_MAX ULONG_MAX.
Find the upper limit, then use a type whose MAX is larger than that
upper limit.
In this case, unsigned long int.

[santosh]

pereges wrote:

On Jun 26, 10:06 pm, Harald van D?k <[e-mail]:

>>
I doubt that is what you read. It's more likely that you read
something similar, and misunderstood. size_t is capable of holding
the size of the largest possible object in the C implementation, but
it's not always, and maybe not even usually, capable of holding the
largest possible integer. On my system, for example, the largest
integer has a value of 18446744073709551615, but I cannot store that
in a size_t, and I cannot even come close to creating any object that
large.

But the value that a size_t type variable can hold must be integer ?

The type of size_t is an unsigned integer, so yes, it must hold an
integer value.

Then what do you mean by largest possible object ?

It's the size of the largest object that an implementation could create.
Since the exact size will vary for different implementations (example
it might be 64Kb under small model DOS, or it might be ~4Gb Linux), the
exact type of size_t is implementation defined. The maximum value a
particular instance of size_t can hold is specified by the macro
SIZE_MAX in stdint.h.

[santosh]

pereges wrote:

For eg :

struct mesh
{
size_t nvert; /* number of vertices */
size_t ntri; /* number of triangles */
.....
};

The reason I want to use size_t is because I've read that it is
capable of supporting size of the largest possible integer in the C
implementation. In my case, the value of nvert can vary from any thing
like 30-40 to even 10 million.

Under C90 the largest possible integer value can be represented by
unsigned long[1]. Size_t may not be sufficient, (example it could be
aliased to unsigned int.) For a C99 based system use uintmax_t if you
need the absolute largest supported unsigned integer type.

1. And the signed variants of course.

[Andrey Tarasevich]

pereges wrote:

...
The reason I want to use size_t is because I've read that it is
capable of supporting size of the largest possible integer in the C
implementation.
...

That's incorrect. 'size_t's range is big enough to store the size in
bytes of the largest possible object in C implementation. That's it.

It is not guaranteed to be capable of storing such quantities as, for
example, the number of different objects. And, of course, it is not
guaranteed to be the largest possible integer.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Richard Tobin wrote:

...
size_t is appropriate for counting things that are represented as C
objects.
...

Maybe I misunderstood you, but there's no guarantee that 'size_t' can
store the total number of C objects I can allocate in dynamic memory.

For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.

--
Best regards,
Andrey Tarasevich

[vippstar]

On Jun 27, 2:29 am, Andrey Tarasevich <[e-mail]>
wrote:

Richard Tobin wrote:

...
size_t is appropriate for counting things that are represented as C
objects.

...

Maybe I misunderstood you, but there's no guarantee that 'size_t' can
store the total number of C objects I can allocate in dynamic memory.

For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.

And what you'd count is the successful allocations, not 'things that
are represented as C objects'.
So indeed, you have misunderstood.

[Richard]

vi******@gmail.com writes:

On Jun 27, 2:29 am, Andrey Tarasevich <[e-mail]>
wrote:

>Richard Tobin wrote:

...
size_t is appropriate for counting things that are represented as C
objects.

> ...

Maybe I misunderstood you, but there's no guarantee that 'size_t' can
store the total number of C objects I can allocate in dynamic memory.

For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.

And what you'd count is the successful allocations, not 'things that
are represented as C objects'.
So indeed, you have misunderstood.

But you would not necessarily use a size_t to store that count.

size_t is generally used as a size or length holder, not the number of
times something has been done.

So he is right. Kind of.

[Richard Tobin]

In article <lz************@stalkings.ghoti.net>,
Keith Thompson <ks***@mib.orgwrote:

>uintptr_t, if it exists, can represent a distinct value for each
possible void* value. Therefore, uintptr_t, if it exists, can safely
be used as an object count.

An application of the "pigeonhole principle".

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Andrey Tarasevich]

vi******@gmail.com wrote:

>>
For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.

And what you'd count is the successful allocations, not 'things that
are represented as C objects'.

Each time I do

char* p = malloc(1);
*p = '\0';

I create a 'char' object with 'allocated' storage duration (it's pointed
by 'p'). So counting these dynamically allocated objects will be
"counting things represented as C objects".

--
Best regards,
Andrey Tarasevich

[vippstar]

On Jun 28, 1:09 am, Andrey Tarasevich <[e-mail]>
wrote:

[e-mail] wrote:

For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.

And what you'd count is the successful allocations, not 'things that
are represented as C objects'.

Each time I do

char* p = malloc(1);
*p = '\0';

I create a 'char' object with 'allocated' storage duration (it's pointed

No you don't, you possibly invoke undefined behavior.
It does not create a char object, it allocates sufficient space to
hold a char value.

by 'p'). So counting these dynamically allocated objects will be
"counting things represented as C objects".

Wrong. You count successful allocations, not the size of an object.

[Ben Bacarisse]

vi******@gmail.com writes:

On Jun 28, 1:09 am, Andrey Tarasevich <[e-mail]>
wrote:

>[e-mail] wrote:

>For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.
And what you'd count is the successful allocations, not 'things that
are represented as C objects'.

Each time I do

char* p = malloc(1);
*p = '\0';

I create a 'char' object with 'allocated' storage duration (it's pointed

No you don't, you possibly invoke undefined behavior.
It does not create a char object, it allocates sufficient space to
hold a char value.

malloc creates space for an object. An object is just a region of
storage whose contents represent values. Do you really want to split
hairs and claim that the object pointed to by malloc's (successful)
return is not a char object, even though it is an object and it can be
used to represent char values?

>by 'p'). So counting these dynamically allocated objects will be
"counting things represented as C objects".

Wrong. You count successful allocations, not the size of an object.

I suspect there must be a language problem here. How can you have any
objection to counting successful allocations as being an example of
"counting things represented as C objects"?

--
Ben.

[vippstar]

On Jun 28, 5:01 pm, Ben Bacarisse <[e-mail]:

[e-mail] writes:

On Jun 28, 1:09 am, Andrey Tarasevich <[e-mail]>
wrote:

by 'p'). So counting these dynamically allocated objects will be
"counting things represented as C objects".

Wrong. You count successful allocations, not the size of an object.

I suspect there must be a language problem here. How can you have any
objection to counting successful allocations as being an example of
"counting things represented as C objects"?

I completely misunderstood "counting things represented as C objects".
Mr Tarasevich is also right. Sorry for the confusion.

[pereges]

On Jun 27, 12:54 pm, Richard Heathfield <[e-mail]:

It is a good idea to ensure that any value coming from an outside source
falls within the range of values that make sense for the purpose. As
someone has noted elsethread, users don't enter integers; they press keys.
If you can make sure they pressed the right keys (or at least, didn't
press the wrong keys), that's always a good place to start.

I think the compiler can take care of it.

I tried the following :

unsigned long v_index /* vertex index ranging from 0...nvert - 1 */

if (v_index < 0 || v_index nvert - 1)
{
printf("Vertex index out of range\n");
}

I got a warning from the compiler:

warning #2130: Result of unsigned comparison is constant.

[vippstar]

On Jun 28, 6:14 pm, pereges <[e-mail]:

On Jun 27, 12:54 pm, Richard Heathfield <[e-mail]:

It is a good idea to ensure that any value coming from an outside source
falls within the range of values that make sense for the purpose. As
someone has noted elsethread, users don't enter integers; they press keys.
If you can make sure they pressed the right keys (or at least, didn't
press the wrong keys), that's always a good place to start.

I think the compiler can take care of it.

I tried the following :

unsigned long v_index /* vertex index ranging from 0...nvert - 1 */

if (v_index < 0 || v_index nvert - 1)
{
printf("Vertex index out of range\n");

}

I got a warning from the compiler:

warning #2130: Result of unsigned comparison is constant.

That warning is beacuse of v_index < 0.
v_index is an unsigned integer. It can never have a negative value,
thus v_index < 0 is always false.
The warning is not correct (nor it needs to be); it's not a constant
expression. A better warning would be "result of expression is always
false".

[pereges]

On Jun 28, 8:21 pm, [e-mail] wrote:

That warning is beacuse of v_index < 0.
v_index is an unsigned integer. It can never have a negative value,
thus v_index < 0 is always false.
The warning is not correct (nor it needs to be); it's not a constant
expression. A better warning would be "result of expression is always
false".

Ok, and are there any issues involved in reading unsigned long
integers from an ascii file ?

[Richard Heathfield]

pereges said:

On Jun 28, 8:21 pm, [e-mail] wrote:

>That warning is beacuse of v_index < 0.
v_index is an unsigned integer. It can never have a negative value,
thus v_index < 0 is always false.
The warning is not correct (nor it needs to be); it's not a constant
expression. A better warning would be "result of expression is always
false".

Ok, and are there any issues involved in reading unsigned long
integers from an ascii file ?

If an ASCII file is one that contains only ASCII representations of text,
then it doesn't have any unsigned long integers in it, so there can't be
any issues involved in reading them, since they aren't there to read.

What you *can* do, of course, is to interpret text representations of
numbers, translating them into numbers internally. When doing this, you
need to be sure that the internal representation you choose is capable of
representing the numbers you are translating.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

pereges said:

On Jun 27, 12:54 pm, Richard Heathfield <[e-mail]:

>It is a good idea to ensure that any value coming from an outside source
falls within the range of values that make sense for the purpose. As
someone has noted elsethread, users don't enter integers; they press
keys. If you can make sure they pressed the right keys (or at least,
didn't press the wrong keys), that's always a good place to start.

I think the compiler can take care of it.

I tried the following :

unsigned long v_index /* vertex index ranging from 0...nvert - 1 */

if (v_index < 0 || v_index nvert - 1)
{
printf("Vertex index out of range\n");
}

I got a warning from the compiler:

warning #2130: Result of unsigned comparison is constant.

It's strange that you didn't get a warning from the missing semicolon.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pete]

vi******@gmail.com wrote:

On Jun 28, 1:09 am, Andrey Tarasevich <[e-mail]>
wrote:

>[e-mail] wrote:

>>>For example, I can successfully execute 'malloc(1)' more times (i.e.
allocate more 1-byte objects) than 'size_t' can count.
And what you'd count is the successful allocations, not 'things that
are represented as C objects'.

Each time I do

char* p = malloc(1);
*p = '\0';

I create a 'char' object with 'allocated' storage duration (it's pointed

No you don't, you possibly invoke undefined behavior.

Possibly.

It does not create a char object, it allocates sufficient space to
hold a char value.

Assuming that (p) does not compare equal to NULL:

(*p) is the lvalue of a char type object.
It does have allocated storage duration.
It wasn't always there;
if Andrey Tarasevich didn't create it, then where did it come from?

N869
3.15
[#1] object
region of data storage in the execution environment, the
contents of which can represent values

6.3.2 Other operands
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void;

When an object is said to have a particular type,
the type is specified by the lvalue used to designate the object.

--
pete