Mixing size_t and other types

[Malcolm McLean]

Some maybe, but not half!

2GB ought to be enough for anyone. What sort of data are you
processing?

 

[Ian Collins]

2GB ought to be enough for anyone. What sort of data are you
processing?

Virtual machines.

 

[Tim Rentsch]

Strangely enough, size_t is commonly used for sizes, so just make size a
size_t and save to agro.

size_t will be an unsigned type.

Thanks. But this variable holds a value that comes from the standard
function "ftell". It'd be something like,

fseek (fp , 0 , SEEK_END);
size = ftell (fp); /* ftell gives me long int. */
rewind (fp);

So I think I won't be able to make it a size_t. Not sure how to go
about this. Any help?

You mustn't assign the return value of 'ftell' to a variable of type
'size_t' because it may return -1L on error. In that case you'd end up
with a nonsensical file position value, [snip]

Right in the sense that the type 'size_t' can be too narrow,
but 'unsigned long' should work just fine, since 'ftell()'
returns a plain 'long'. The error indicator value of -1
can be tested for in an 'unsigned long size' using a regular
equality comparison (ie, == or !=).

How does one distinguish between the error return of -1L (which is
converted to ULONG_MAX) and the actual return of ULONG_MAX?

The original source was type 'long', so most likely the value
of ULONG_MAX cannot occur in the original value. It can in
the sense that the Standard allows LONG_MAX == ULONG_MAX (ie
'unsigned long' has only the non-negative values of 'long',
and no others), but since 'unsigned long' must be at least 32
bits, that would make such an implementation have at least 33
bits for 'long', and all in all it seems very unlikely, or
even very very unlikely. Even so it may be worth putting in a
static assertion in some form to ensure one's code isn't going
to be run on a DS9000.

 

[chrisbazley]

<--
I agree with you up to a point, but it is still prudent when designing
a small car to document in the driver's handbook that it wasn't
intended for elephants and design the doors to debar elephants -
rather than unexpectedly turning itself inside out or destroying the
universe when the first elephant tries to climb aboard.
-->

by this reasoning, no one could use pointers without first checking they
weren't NULL either...

faster and easier in most cases is to assume that the pointers are not NULL,
and only really bother with checking in cases where a NULL is a reasonably
expected result...

Actually I do assert that pointers are non-NULL before dereferencing
them, as a matter of habit. Regardless, I don't think that is a valid
comparison because it isn't possible to pass a null pointer as direct
input to a C program, whereas is certainly is possible to specify
input files with unexpected characteristics.