bug-gnulib
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]