Re: The annotated annotated annotated C standard part 3



On Sun, 20 Jan 2008 03:24:36 -0800 (PST), spinoza1111
<spinoza1111@xxxxxxxxx> wrote:

On Jan 20, 3:55=A0am, c...@xxxxxxxx (Richard Harter) wrote:
On Fri, 18 Jan 2008 22:09:04 -0800 (PST), spinoza1111

<spinoza1...@xxxxxxxxx> wrote:

[snip]

Programmers need to be able to speak and write about the pragmatic
effect of their code. However, the ability to write comments
(exhibited so wonderfully here in comp.programming by Richard Harter's
Beautiful Code, written in 1990, for memory allocation) is destroyed
when some non-programmer like you appoints himself not as a critic but
as a censor. When the ability to use language is so checked by the
dull insistence that words have not a range of meanings but fixed
meanings, the ability to think atrophies shortly thereafter.

[snip]

It is always gratifying, of course, to be complemented on one's
writings and I do thank you. =A0That said, this thread may not be
an entirely satisfactory venue for discussing commenting code.

Yes. Abandon all hope ye who enter here.

Tell me, why not just upgrade the 1990 code? The identifiers are too
short for my taste, but it looks better than more "modern" stuff.

That's what I'm doing. I agree that the identifiers are too
short; however that is an artifact of the line by line
commenting. In turn, that is a style inherited from assembly
language programming. The bulk of 1990 code was written circa
1983 when there was no guarantee that identifiers could be longer
than six characters.

As it happens, updated versions of that code are still in use in
industry; however I don't have rights to the updated versions.

You could avoid a problem I understand exists in malloc(), which is
that it cannot be called recursively as when a signal handler uses it
to handle an error in malloc().

This would be to combine all the changeable information about a single
memory request and the status of memory into a single struct and force
the caller to pass an instance of this struct. Boom, your code is
static and "re-entrant" which is what malloc() should have been.

This doesn't solve the problem of handling an error in malloc, or
at least the inability to allocate, because that is a resource
failure issue. The signal handler needs space from malloc that
malloc can't provide. An implementation can get around this by
providing a error handling call into the malloc package which in
turn reserves some memory for error handling calls. This is a
solution with problems.

Incidentally, the 1990 code is a wrapper around malloc, rather
than a replacement for malloc.


[Why am I talking about C, a language I 'hate'? Because I lack the
misplaced geeky love of artifacts, complementary to that hate, which
replaces knowledge in programming and becomes a loyalty to existing
social arrangements. But, I digress.]

Of course, all your callers would then "know" all the dirty little
secrets of your malloc. You could even give them a nifty little
routine to print out the complete state of malloc, a precursor of
toString() in C Sharp and Java.

And the complete state would not exist only in the "activation"
struct. It would also be the chains in memory UNLESS the memory were
part of the activation struct.

You'd get OO encapsulation, but no hiding. Hiding information
overrated?

Actually you can use this technique and have information hiding.
The trick is to hide the private data under a void * pointer,
e.g.,

struct spacedata {
void * private;
void * data;
};

The "private" pointer points to the state data; however it can
only be read by the package. However the "struct" technique
isn't convenient because the allocations and deallocations can be
in separate places.



.



Relevant Pages

  • Malloc statistics patch
    ... Now that the UMA changes to use critical sections instead of per-cpu mutexes ... memory allocation patch previous posted. ... - Introduce per-cpu malloc type statistics, ... - If we're willing to abandon 5.x backport, we can clean up 'struct ...
    (freebsd-performance)
  • Re: The annotated annotated annotated C standard part 3
    ... Beautiful Code, written in 1990, for memory allocation) is destroyed ... When the ability to use language is so checked by the ... You could avoid a problem I understand exists in malloc(), ... the caller to pass an instance of this struct. ...
    (comp.programming)
  • Re: A malloc question
    ... reliably store 100 chars followed by a struct in this memory, ... the alignment of p+100 may not be suitable for the struct. ... the paddings for memory alignment are ... malloc() will see a request of 24 byte allocation. ...
    (comp.lang.c)
  • Re: Need clarity on structure alignment
    ... I remember seeing something that left me with the impression that C guarantees that a struct will be aligned on a pointer-size boundary (using ... If he uses malloc() to obtain memory for a struct, ...
    (comp.lang.c)
  • Thank You -- Thomas J. Gritzan
    ... Thomas -- Your suggestion to malloc() out a block of memory was the ... Below are some details of my memory issues ... ... As a work around solution I guessed a ram disk would solve the ... persistence will frustrate the off topic police and give them a target ...
    (comp.lang.c)