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

[Keith Thompson]

On Jun 27, 11:15 am, (e-mail address removed) (Richard Tobin) wrote: [...]

I don't think there's guaranteed to be any type that can count
all the allocated objects, though uintptr_t must work if it exists.

uintptr_t is not relevant to counting successful allocations.
It could be that malloc() always succeeds.
Usually there's something else that puts an upper bound.
For example, when you count allocations, you count allocations for /
something/, for example, lines in your text editor.
You can simply put the 'unsigned long' upper bound which is at least
2^32-1, sufficient practically for any text file.

The number of distinct objects cannot exceed 2**N, where N is the size
in bits of type void*.

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.

size_t cannot, in general, because it's only guaranteed to be big
enough to represent the size in bytes of a single object (though
calloc() introduces some confusion here). For example, a system with
segmented addresses might have 64-bit pointers, but only allow
2**32-byte objects; size_t would only have to be 32 bits, but
uintptr_t would have to be 64 bits.

(Most modern real-world systems have flat address spaces, so size_t is
big enough to cover the entire address space, but it's not
guaranteed.)

 

[Richard Tobin]

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

 

[Andrey Tarasevich]

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

 

[vippstar]

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]

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?

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"?

 

[vippstar]

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]

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]

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]

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 ?