Re: new module for temporary files in temporary directories

[Ben Pfaff]

Paul Eggert <address@hidden> writes:

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

I do not think that signal handlers are perfectly analogous to
threads, although I will not deny that as both are examples of
asynchronous behavior, they are certainly related.

The issue at hand, as I understand it, is not even the general
behavior of signals.  It is the behavior of fatal signals.  That
is, a the program terminates without ever returning from the
signal handler.  This is much simpler than the general problem of
synchronizing many threads.  It is a little like a single thread
that runs for a while, then switches to another thread a single
time, and then both threads terminate.

>> 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 won't make a claim that the signal handler in the above code is
guaranteed to see 1 if called during getchar, because the
assignment in main does not access a volatile object.

However, I believe that if the assignment in main were changed to
the following, then the signal handler would be guaranteed to see
1 in x if the signal arrived in getchar;
        *(sig_atomic_t volatile *) &x = 1;
To me, this is exactly what the C99 rationale is saying in 6.7.3,
toward the end:
      If it is necessary to access a non-volatile object using
      volatile semantics, the technique is to cast the address of
      the object to the appropriate pointer-to-qualified type,
      then dereference that pointer.
With the cast, `x' is accessed as a volatile object, because it
is accessed through a volatile lvalue.  This is consistent with
the definitions of "object" and "lvalue" in the standard (and that
is why I quoted their definitions earlier).

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

I am not confident that I understand volatile correctly, either,
but I do want to help.  I hope that my comments can clarify,
rather than throw additional mud on already muddy ground.

Maybe I am not being helpful because I misunderstood your
original objection.  Perhaps all this is moot because Bruno's
module does not actually contain any casts to volatile.

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

I was aware that there had been a proposal, but not of the
details.  Thanks for the pointer (and for the Open Group version
too).
-- 
"But hey, the fact that I have better taste than anybody else in the
 universe is just something I have to live with. It's not easy being
 me."
--Linus Torvalds