"free space" with declared type

[Mark Piffer]

Sorry if this ends up out-of-thread but Google posting seems to have a
temporary problem quoting articles.

That's up to you and whether you are convinced or not.

Another place to look would be the rationale which has a reasonable
section on the whole basis of the aliasing rules.

Lawrence

Am I correct in conjecturing that the basic conclusion of this UB is
that one can't write an allocator of his/her own? Without having free
storage at hand (i.e. having only objects with declared type) one is
doomed to use the storage the way it was declared or not at all? 8(
This renders many embedded application non-conformant which can't use
"malloc" but could do well with a constrained mini allocation scheme
in an array of char - I am scared.

Mark

 

[Chris Croughton]

Sorry if this ends up out-of-thread but Google posting seems to have a
temporary problem quoting articles.

Google has problems, period!

Am I correct in conjecturing that the basic conclusion of this UB is
that one can't write an allocator of his/her own?

You've missed one word and one phrase -- 'portably' and "general
purpose". You can of course write an allocator for your specific
environment which is general purpose like malloc (indeed that's what the
implementation of malloc does for that environment). It won't be
portably to any C compiler and environment, though (although you can
make it so that it is portable to most of the ones you're likely to
use).

Similarly, you can write an allocator which is fully portable for a
specific type or set of types. Trivially, you can make one which is
portable for char, by using a union you can make one which is portable
for all integral types, etc., but you can't make one which gives
alignment suitable for any purpose without knowing machine details.

Without having free storage at hand (i.e. having only objects with
declared type) one is doomed to use the storage the way it was
declared or not at all? 8( This renders many embedded application
non-conformant which can't use "malloc" but could do well with a
constrained mini allocation scheme in an array of char - I am scared.

You needn't be. Embedded programs are not portable in the same way,
they are implicitly (and sometimes explicitly) tied to a specific
architecture or set of architectures and hardware, so it is no problem
to have a specific allocator, preferably grouped in a library with other
machine specific functionality. All you then need to do, if the rest of
your program has been implemented portably, is to change the specific
parts which depend on the architecture (keeping the interface the same).

The point is that if you (or whoever is implementing the allocator)
knows what they are doing there is no problem. For instance, if you
know that the worst case alignment your program needs is a long then you
can do your own alignment to sizeof(long). If you know that your
machine has linear addresses which correspond to values in an unsigned
long then you can do appropriate arithmetic on them. It just isn't
portable to any architecture you might ever find -- but it may well work
for all machines you will ever find in practice which want to use your
code...

Chris C

 

[Lawrence Kirby]

Sorry if this ends up out-of-thread but Google posting seems to have a
temporary problem quoting articles.


Am I correct in conjecturing that the basic conclusion of this UB is
that one can't write an allocator of his/her own?

It is already impossible to write a portable general allocator like
malloc() because you can't portably determine what alignment meeds the
requirements of all objects the implementation can support.

In order to write your own allocator you have to get memory from
somewhere. You could use some extension to reserve it in which case you're
outside the scope of the C standard immediately. The alternative, which
might make sense for an embedded system, is to use a static array.


That is
a problem though because the aliasing rules are very strict for declared
objects. OTOH you would probably need to use an extension to get/set the
the size of the array anyway.

Without having free
storage at hand (i.e. having only objects with declared type) one is
doomed to use the storage the way it was declared or not at all? 8( This
renders many embedded application non-conformant which can't use
"malloc" but could do well with a constrained mini allocation scheme in
an array of char - I am scared.

The aliasing rules are strict for declared objects so yes that is a
problem. OTOH you would probably need to use an extension to get/set the
the size of the array anyway. Essentially an allocator isn't going to be
writen in 100% portable code. That isn't a huge problem in practice.

Lawrence