Re: The annotated annotated annotated C standard part 3

On Jan 20, 3:55 am, 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.  That 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.

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.

[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?
.

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: 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)
  • 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: swsusp problems [was Re: Your opinion on the merge?]
    ... struct range * first; ... int allocs; ... we allocate a special memory pool. ... the atomic copy of pageset1. ...
    (Linux-Kernel)