Re: malloc patch for 2.2.4

[Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>]

> Anything that is not explicitly specified in the standard is undefined by
> default.  The compiler is free to do _anything_ in such a case.

I agree that it is free to do this, and I do respect standards as far
as I can.  In this case, the more useful behaviour should occur, IMHO.

> If you want to write a threaded program, you must program with thread
> safety in mind.  That means using mutexes where it matters.  There is
> nothing else that can garantee atomicity.

For full portability, you're correct, no question.  Specific
platforms, however, can and do make more stringent atomicity
guarantees (all of the ones targeted by ptmalloc have atomic access to
pointers, for example), and the compiler should not spoil this by such
a useless re-load from memory.  If I can stop it by specifying
'volatile' or a switch, then so be it, I could live with that, even
though I would rather do without it.

> |> Doesn't this forbid a re-read from 'a' for 'tmp' even in the
> |> single-thread, but possibly signal-interrupted case?
> 
> No, a signal handler is only allowed to write to objects of type "volatile
> sig_atomic_t".

You're correct, I forgot that 'static storage duration' has nothing to
do with the 'static' qualifier.

Regards,
Wolfram.