Re: new module for temporary files in temporary directories

[Bruno Haible]

Paul Eggert wrote:
> > 'malloc' is one such function.
>
> My intuition is the oppposite; I would expect 'malloc' to have more
> problems than a random user function, since the compiler "knows" more
> of malloc's properties.

The compiler knows about it, but its code is quite complex, therefore hardly
inlinable if the 'size' argument is not known at compile-time.

> > But there are other people who need volatile: The Linux kernel community.
>
> Yes, but as I understand it these people compile only with GCC, and
> even then only with certain option combinations.  A few diehards try
> to use other compilers but are also limited to subsets of what's
> available.  We don't want to be quite so limited in gnulib code.

The Intel compiler people also have the declared goal of supporting the
Linux kernel. They spent a lot of effort adding support for __asm__ in gcc's
semantics; I don't think they would drop this support for a different
semantics of 'volatile'.

Then there is also the OpenSolaris kernel, which uses the 'volatile' keyword
(both in field declarations and in casts) in the same sense. The SunPRO C
compiler is committed to support this.

That makes 3 major compilers which cannot change the 'volatile' handling
due to kernels.

> If you don't mind my continuing to play devil's advocate (:-), let me
> turn it around and ask the reverse question.  Can you demonstrate a
> bug that would be introduced if we removed the 'volatile's, by
> referring to the machine code that is generated by GCC on x86, or by
> some other specific implementation?

Not in gnulib's code and not on x86 (because there are so few registers
on this platform that gcc hardly does any scheduling), but on SPARC,
PowerPC, or x86_64, yes. libsigsegv's tests/sigsegv2.c definitely fails
with gcc 3.3.4 on PowerPC if 'volatile' is omitted. I looked at the code
generated by gcc and saw the instruction reordering done by gcc.

Bruno