[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new module for temporary files in temporary directories
From: |
Paul Eggert |
Subject: |
Re: new module for temporary files in temporary directories |
Date: |
Wed, 05 Jul 2006 10:46:28 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Ben Pfaff <address@hidden> writes:
> This is a particularly pessimistic interpretation of the
> standard,
You think _I'm_ pessimistic! You should hear Nick MacLaren and Dave
Butenof. Here's a sample quote (in the threading area):
... the use of volatile accomplishes nothing but to prevent the
compiler from making useful and desirable optimizations, providing
no help whatsoever in making code "thread safe".
Dave Butenhof, comp.programming.threads (1997-07-03)
<http://groups.google.com/group/comp.programming.threads/msg/bd2cb64e70c9d155>
> 5.1.2.3p5 talks about the type of an object, with no
> reference to how the object was defined:
>
> The least requirements on a conforming implementation are:
>
> - At sequence points, volatile objects are stable in the
> ^^^^^^^^^^^^^^^^
> sense that previous accesses are complete and subsequent
> accesses have not yet occurred.
As I understand it, under your interpretation this signal handler:
#include <stdio.h>
#include <signal.h>
sig_atomic_t x;
void handler (int sig) { sig_atomic_t volatile *p = &x; *p = 0; }
int main (void)
{
signal (SIGINT, handler);
x = 1;
getchar ();
return x;
}
always has well-defined behavior, since the signal handler simply
stores 0 into a sig_atomic_t volatile object and it's immaterial how
the object was defined. So if a signal arrives during the call to
getchar, then 'main' must return 0 and not 1.
But this interpretation doesn't correspond to how compilers behave.
If the type sig_atomic_t is plain 'int', for example, a compiler is
entitled to cache other references to x's contents even in the
presence of signals. Both GCC and Sun C do this, e.g., on 64-bit
SPARC they don't bother to set 'x' before getchar returns. More
generally, I don't see how an object can be both volatile and
nonvolatile at the same time: it has to be one or the other. Yet
lvalues of both kinds can exist simultaneously.
I suspect that I am simply misunderstanding your argument (which is
not uncommon in this area!). If so, then if you could flesh out the
argument a bit, that might help. (But I should warn you that I've
never yet understood "volatile", despite my asking some very bright
people what it actually means. :-)
PS. MacLaren proposed a change to the C standard which would in his
opinion fix some (but not all) of the problems with respect to signal
handling and volatile; see
<http://www.davros.org/c/public/pcuk0097.txt>.
However, this proposal was not accepted.
He later proposed something similar to the Open Group for Posix; see
<http://www.opengroup.org/austin/mailarchives/ag/msg07173.html>.
However, this proposal has been ignored by the Open Group as well.
I suspect this is mainly because the problem area is just too hairy
and that consensus cannot be achieved on what 'volatile' actually
means.
Re: new module for temporary files in temporary directories, Bruno Haible, 2006/07/20