Keith said:
Note that SIZE_MAX is an upper bound on the value that can be yielded by
sizeof, not necessarily the least upper bound. There is no defined
constant (that I know of) that actually tells you the maximum size of an
object, which could be substantially smaller than SIZE_MAX. SIZE_MAX is
merely the maximum value of the unsigned type chosen to represent sizes.
(Consider the old m68000, which had 24-bit addresses but 16-bit and
32-bit integers.)
D'oh. Uno suggested votes. I'm genuinely curious as to who might
perceive benefit from a theoretical 'OBJECT_MAX' integer constant
expression which yields the maximum size (in bytes/chars) of an object
which the implementation guarantees well-defined behaviour for. It
might help Mr. J. Kelly's 'trim', and has my vote.
Such could allow for assertions on integers to be added to pointers and
could even help to answer "will my implementation honour this 'calloc'
or reject it as absurd before looking for available space?" to which
experts could reply, "You're not using 'OBJECT_MAX', so it's difficult
to know."
It might be easy to simply make this 'SIZE_MAX'.
On many systems, uintptr_t is likely to be the same type as size_t, but
that assumes a monolithic address space. You might, for example, have
64-bit addresses and 16 exabytes of address space, but only up to
4-gigabyte objects (32 bits), so uintptr_t could be 64 bits while size_t
is only 32 bits.
Aha.
It's also a matter of documentation; if you using uintptr_t, it's
clear that you're doing it because you want an unsigned integer
type that can represent addresses. (You'll also get a compile-time
error if there is no such integer type.)
Fortunately, we can check for 'INTPTR_MIN' and family to get a clue as
to 'intptr_t' availability.
There's no way to determine whether uintptr_t or intptr_t is preferred
for a given system, but I'm not sure what you'd do with that information
anyway.
In principle, objects themselves don't (necessarily) have types.
Thank goodness. That is definitely a characteristic about C which can
be useful for programmer compatibility deliberations.
An object is merely a "region of data storage in the execution
environment, the contents of which can represent values". (Note:
"*can* represent", not "represents".) A type is imposed by the
lvalue (expression) used to refer to the object. For declared
objects, this is typically the type used in the object declaration;
for allocated objects, some type has to be imposed.
Agreed.
For any context where you care whether an object is an array or not,
you'll be using some type to access it. That type will clearly be
an array type or a non-array type.
I'm not at all sure that's sufficiently clear. If it isn't,
could you rephrase the question and/or provide an example?
"Pure" pointers (to non-array object types) are a popular choice for
working with allocated array objects (whatever that means; we have no
type) from memory management functions, for some reason. Probably
because of their brevity in contrast to pointers to array types.
Do these "pure" pointers to allocated storage have anything to say about
the number of elements in the array object pointed-to? Similarly,
union forty_two_doubles {
double d;
char space[sizeof (double) * 42];
} foo;
double *pure = (double *)&foo;
Here we have nice alignment and clearly enough space for 42 'double's,
but different programmers reading the same Standard (or draft) have
different expectations for what kinds of pointer arithmetic is
well-defined upon 'pure'.
A: It doesn't pointer to a 'double', but to a 'union'!
B: It might point to 42 of them!
C: You must use '&foo.d'!
D [in a recognizable voice]: Nobody ought to write such code; it's worse
than stupid! Forget all about it. *Jedi*hand-wave*
E: The bounds are implementation-defined.
F: The bounds are undefined.
G: I only see a single 'double'. There's a single-element array of
doubles, at most.
H: It's aligned for 'double'. What does 'sizeof foo / sizeof (double)'
yield?
I: You have to cast to 'double(*)[sizeof foo / sizeof (double)]' first!
That is, someone might have an expectation that pointer arithmetic is
well-defined without any sign of array types anywhere, or with an
unrelated array-type. We do have the beautiful footnote 91 in
'n1256.pdf' near 6.5.6... But it might be nice if this was crystal
clear from a C Standard. Something like:
"An addressable object or an addressable contiguous range of objects
shall be considered to be an array object for any element type, only if
the object or range is suitably aligned for such an element type; the
count of elements in the array is the maximum number of contiguous whole
elements that would consume less than or equal to the size of the object
or range.(footnote)
(footnote) It follows from this and the alignment and size of 'char'
that any non-bit-field object not having 'register' storage-class can be
treated as 'array of char'."
Unfortunately, such might warrant additional definition for what array
object a pointer points into in the case of multi-dimensional arrays.
For example, a pointer pointing one-past: If it also happens to point to
an element of the same pointed-to type, can we then add a non-zero
integer to this pointer without overflow? Ought the answer to be
implementation-defined, so programmers can find out?
