get size of malloc'd object

[J. Eric Roskos]

> Depends on what you mean by "portable".  Certainly, it is possible to use
> this number in an implementation-dependent way; but there are natural and
> non-implementation-dependent ways to use the information.  E.g., if one is
> allocating character strings and one of them grows, one can try to fit the
> expanded string into the allocated size, and only reallocate (and reset all
> the pointers to the data) if it won't fit.

Well, actually it depends on some other factors, just fairly abstract ones
(and thus debatable).  According to the System V manual, "Malloc returns a
pointer to a block of at least _size_ bytes suitably aligned for any use."

Notice that this places no upper bound on the size that's actually allocated.
Now, you can argue "well, obviously it can't be more than the number of
bytes representable in an int", or something of that nature, but such an
argument wouldn't hold water in any formal proof.  The only thing it says
is *at least* that many bytes.

The problem is that, unless the definition is constrained more, it makes
it impossible to prove a program that uses the "actual size allocated"
correct.  Suppose you store the actual size allocated in an int in your
program.  Then I can argue that on some implementation, the maximum
actual size allocated requires a long int.  If you use a long int, I
can argue that it requires 2* the number of bits in a long int.  And so
on.  Since there's no upper bound specified for the size, there's always
a risk of truncation.

This seems to be somewhat abstract and theoretical, but the problem is
really that there's an "unknown variable" involved that's outside
the program, and it makes it hard to make assertions about the program's
portability to other environments since the variable changes according
to the environment.  You can think of more realistic examples; e.g.,
the situation where you want to save space by storing the size in a small
number of bits in a word, and it'll work fine for one implementation but
not another; but that gets into other portability problems of C (e.g.,
not knowing how many bits is really in an "int", etc.) and it wasn't
my intent to be arguing over the existing problems with C, just the
ones that might be avoided in a new feature.

I agree, however, that for "most cases" the "actual size allocated" might
be useful.  But it's difficult to see why, other than to avoid wasted space,
you would really need it; and my original reasoning in my original comment
was that you shouldn't provide features that introduce these sorts of
problems just out of a "liberty and freedom" approach to C -- I think you
shouldn't introduce arbitrary constraints, but there's a fine but definite
line between arbitrary constraints, in many cases, and purposeful ones.
It's just that the purposeful ones are sometimes esoteric.

If you wonder why anyone would be concerned with formal proofs, it's just
that more and more "real world" applications (especially those for the
gov't) require them, and the inability to do them well for C is one of
the reasons so many people favor Ada.  Personally I like C and would
rather have a "disciplined C".
-- 
E. Roskos
(See net.net-people.)