Re: (ITS#5248) non-atomic signal variables

[h.b.furuseth@usit.uio.no]

Howard Chu writes:
> OK, you're right, it's trivial, and I see that the configure script
> already #defines sig_atomic_t to int if the system doesn't already
> define it. So your suggested changes are harmless, go ahead and make
> them. If you're going to that trouble, you should change gotintr to
> use an explicitly defined contiguous range of values.

OK, later.. that's why I filed an its first (in particular, need to look
at WAKE_LISTENER first.)


Which makes the rest of this reply irrelevant to the ITS, so skip it if
that helps your blood pressure:

> Backward compatibility only reinforces my point, since int has always
> been atomic in the past.

Where do you get that from?  A brief search find nothing like that in
the draft and standard versions I've lying around.  It would also mean
that sig_atomic_t would be a pointless type.

>> Otherwise the standard would not have needed to define sig_atomic_t.
>
> Note that sig_atomic_t is an *optional* part of the standard;
> implementations are not required to provide it.

Irrelevant.  Freestanding implementations need not provide it (nor
most of the rest of the C library), but <signal.h> requires it.

> The standard says it is impossible for arithmetic operations on valid
> values to generate trap representations. Think about it - if it were
> *possible* for intermediate states to be invalid, (...)

A signal breaks the rest of the execution model.  A variable need not be
in an "intermediate state" according to that model when a signal
arrives.  Otherwise C could not use *any* inherently non-atomic types,
which would rather limit which CPUs could support C.  That's why the
standard says signal handlers can do so aburdly few things in the first
place.

> Nobody is stupid enough to design a machine like that, and the
> standard guarantees that programmers never have to worry about such a
> stupidity ever existing.
> (...)
> Not on any machine ever built (for which a C translator exists).

On the countrary, the existence of such hosts is precicely why the
section about signal handlers explicitly contradicts you.  And as Doug
Gwyn said, even the little part it does guarantee was hard to get
agreement for.

-- 
Regards,
Hallvard