"free space" with declared type

[Mark Piffer]

On 21 Dec 2004 07:20:54 -0800, Mark Piffer

Indeed, but in practice most real-world programs don't need that extreme
level of conformance (anything using network or other libraries, for a
start).

I agree, but the task in question (a 'polymorphic' stack) is rather
only algorithmically challenging, and not exhausting the architectures
specifics.

Yes, that's what malloc does (in fact it often wastes more than that
because it might have to align for a type you don't need).
ok.

Well, you could have a separate allocator for each type. But in
practice if you align to the largest type (not allocate in units of that
type, just align to it) that must work. So you can have:

union BiggestType
{
short s;
int i;
long l;
};

then align the start of the allocated area to sizeof(union

BiggestType).
I think I haven't made myself sufficiently clear on this point: given
a number of completely differing aggregate types (the local variables
for the states in a statemachine e.g.) I want to stack many different
of them in my pseudo-heap. I can't exhaustively write allocators for
all types because I have only one array of char and as far as I
understand it, the allocators would need to work each on it's own
storage area.

I work on mobile phone software, we do the same (except that reading and
writing flash ROM and other hardware access also has to be ported, and
running on several OSs with different task models means that those
interfaces need a common layer as well).

Not imposing any task model and therefore not leaving the standard
scope in this respect is what came naturally with the construction of
a reentrant statemachine hierarchy - if I only could place my dynamic
memory (behaving nicely like a stack as I said) inside a gobal array
of char. I know that it is portable to my desktop and to many other
architectures but it is not ISO-C because the standard rather prepares
for unlikely future I-am-the-omniscient-trash-heap pointer
implementations which will cry foul if I ever touch the array of char
with another type. I can live with the aligment issue, as I said, but
the access restriction to the declared type seems artificial to me - I
hope that Chris Torek or Keith Thompson can come up with a convincing
counter argument and prove me wrong.

How about endian and alignment issues in your structures? It is not
possible to ever run things totally 1:1 in different environments, and
that's nothing to do with the language used it's because the environment
is part of the problem.

Nope. As I said, only in the last five or so lines the architectural
dependency shows up. Only in this place it matters to me if I write
octets or whatelse into a real memory (also, this is insignificant as
far as debugging is concerned). The big rest is pure algorithmic work
and as such expressable in standard C. Note that I do not want a 1:1
octet-wise match of my data structures on the mcu and in the desktop,
I just want it identical as far as the standard goes. All details like
different ranges, alignment, endianess and padding are of no concern
for the program logic to work, until I reach the memory interface.

If you want Java you know where it is. And it's slow and unwieldy
because it hides all of those 'messy' things and pretends to be running
on the same machine everywhere (except that it fails at that as well!).
There is no such thing as a totally portable embedded program, because
by its nature it deals with things outside the C standard. You can
however come arbitrarily close to it for the majority of the program,
leaving the messy bits to port.

Chris C

You misinterpreted me. I explicitly *do not* strive for java-ness; it
is this exact and only thing that a once declared object can't be used
as something else that I claim comes at an unjustifiable high price
for embedded programming. Don't get me wrong, I don't think that we
should go for complete anarchy in types and objects but a special case
for unsigned character is in IMHO really worth a thought. malloc is
allowed to do it, why is it impossible for the application to have
objects with no declared type but defined size?

Mark

 

[Chris Torek]

... I can live with the aligment issue, as I said, but
the access restriction to the declared type seems artificial to me - I
hope that Chris Torek or Keith Thompson can come up with a convincing
counter argument and prove me wrong.

Unfortunately, the "access only as declared type" thing seems to
be what the (C99) Standard says (C89 does not have this particular
wording, so it is not as clear there). If this is indeed the case,
we must conclude that writing your own allocator in this fashion
is inherently non-standard.

Then again -- so what? Put the allocator in a separate file and/or
library, and if it breaks when you port the code to some other
machine, write a different implementation for that machine. Either
it can be done at all (so your problem can be solved), or it cannot.
Abandoning Standard C loses only one thing: *assurance* that the
module you wrote will work. While such assurance is worth
something[%], the price of nonportability is surely exceeded by
the value of solving the problem.
-----
[%] The value of this certainty depends on both the frequency and
cost of supplying different modules for different C systems. Compare
with, e.g., a threading library, or routines to implement graphics
using OpenGL vs X11 vs Microsoftware vs whatever, and so on.
-----

... but a special case
for unsigned character is in IMHO really worth a thought. malloc is
allowed to do it, why is it impossible for the application to have
objects with no declared type but defined size?

While this is not quite the same thing, I think it is unfortunate
and/or "wrong" that neither C89 nor C99 give a C programmer the
tools required to write a malloc()-like function in Standard C.