Re: new module for temporary files in temporary directories

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> In theory, yes. In practice, we can stop the propagation of 'volatile'
> at function boundaries, for functions we know the compiler will not
> inline. (Only if the compiler inlines a function, it has the chance to
> reorder the statements in ways that were not foreseen by the programmer.)

Unless I'm misunderstanding you I can think of some counterexamples.
For example, if F calls G and F has some local variables whose
addresses are never taken, then a compiler can know that G cannot
possibly access those variables, and can reorder statements in F so
that they are executed before G was called, when the user thought they
were executed after (or vice versa).  The problem is not limited to
local variables; it can also occur with static variables.  I suspect
it can also occur with objects accessed via 'restrict' pointers, and a
few other cases.

Also, as a practical matter, there are implementations where linkers
inline cross-module.  See, for example,
<http://www.ddj.com/dept/cpp/184403879>.

In theory implementations could even inline at runtime; I don't know
of any that do now, for C, but possibly this will happen in the future
as compiler technology improves.

> '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.

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

>> In <http://lists.gnu.org/archive/html/bug-coreutils/2004-04/msg00154.html>
>> I fixed this problem by rewriting 'ls' to use almost-C89 signal
>> handling, and this fixed the problems for good.
>
> Maybe one reason of this is that now you avoid doing output to file
> descriptor 1 while the main program uses stdout?

Yes, that was a related issue.

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?  If you can, then obviously the
'volatile's help in practice; if not, then perhaps they're not needed.