signals == software interrupts ?
in [Unix Programming]
|
From: David Schwartz on 10 Feb 2010 10:31 On Feb 10, 1:51 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > David Schwartz <dav...(a)webmaster.com> writes: > > On Feb 8, 7:48 am, Jorge <jo...(a)jorgechamorro.com> wrote: > > [signal handler setting assigning to an int object] > > > Because your signal handler is broken. > > "If the signal occurs other than as the result of calling the abort or > > raise function, the > > behavior is undeï¬ned if the signal handler refers to any object with > > static storage duration > > other than by assigning a value to an object declared as volatile > > sig_atomic_t[.]" - C99 7.14.1.1 > This except doesn't support the notion that 'the signal handler is > broken'. Yes, it does. It doesn't 100% *prove* it's broken standing by itself, but it most definitely does support the notion. > Its behaviour may[*] be undefined, according to the > C-standard, but this just means the code is not strictly conforming C > but only conforming C (by virtue of being acceptable to a conforming > application). It doesn't "just" mean that, that's one of the things it means. It also means it may be broken, and in this case, it *is* broken. (That it could have violated this rule and not be broken doesn't change the fact that this code *is* broken *because* it violates this rule.) > Since the code was also using library functions not > defined by the C-standard, it is 'just' conforming C either way. > The meaning of 'not defined by the C-standard' is still just 'not > defined by the C-standard'. So what? I never claimed it was strictly-conforming or that it was broken just because it was strictly-confirming. You simply changed my claim to say something I didn't say, then pointed out that what you added was wrong. >     [*] sig_atomic_t is a type which is supposed to be defined in >     the signal.h header. As such, it must be an alias for another >     type and in this particular case (Linux/ glibc), this other >     type is 'int'. Consequently, the behaviour is not undefined >     for this implementation and not for any other which also >     typedefs sig_atomic_t as int. Again, not what I said. I said the *this* signal handler was broken *because* it violated this rule. That is true. DS
From: Rainer Weikusat on 10 Feb 2010 11:02 David Schwartz <davids(a)webmaster.com> writes: > On Feb 10, 1:51 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: >> David Schwartz <dav...(a)webmaster.com> writes: >> > On Feb 8, 7:48 am, Jorge <jo...(a)jorgechamorro.com> wrote: >> >> [signal handler setting assigning to an int object] >> >> > Because your signal handler is broken. > >> > "If the signal occurs other than as the result of calling the abort or >> > raise function, the >> > behavior is undefined if the signal handler refers to any object with >> > static storage duration >> > other than by assigning a value to an object declared as volatile >> > sig_atomic_t[.]" - C99 7.14.1.1 > >> This except doesn't support the notion that 'the signal handler is >> broken'. > > Yes, it does. It doesn't 100% *prove* it's broken standing by itself, > but it most definitely does support the notion. It doesn't. 'Undefined behaviours' is defined as behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements Consequently, the C-standard 'imposes no requirements' upon the behaviour of a conforming implementation when encountering a signal handler which assigns a value to an int. And that's the end of the story insofar the C-standard is concerned, which is, after all, supposed to standardize (some aspects of) C implementations and not programs written in C. An implementation might be 'broken' if it is claimed that it would adhere to the C-standard but doesn't, but code which produces "output dependent on any unspecified, undefined, or implementation-defined behavior" is just "not maximally portable among conforming implementations".
From: Barry Margolin on 10 Feb 2010 11:42 In article <87zl3h84fw.fsf(a)fever.mssgmbh.com>, Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > David Schwartz <davids(a)webmaster.com> writes: > > On Feb 10, 1:51 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > >> David Schwartz <dav...(a)webmaster.com> writes: > >> > On Feb 8, 7:48 am, Jorge <jo...(a)jorgechamorro.com> wrote: > >> > >> [signal handler setting assigning to an int object] > >> > >> > Because your signal handler is broken. > > > >> > "If the signal occurs other than as the result of calling the abort or > >> > raise function, the > >> > behavior is undefined if the signal handler refers to any object with > >> > static storage duration > >> > other than by assigning a value to an object declared as volatile > >> > sig_atomic_t[.]" - C99 7.14.1.1 > > > >> This except doesn't support the notion that 'the signal handler is > >> broken'. > > > > Yes, it does. It doesn't 100% *prove* it's broken standing by itself, > > but it most definitely does support the notion. > > It doesn't. 'Undefined behaviours' is defined as > > behavior, upon use of a nonportable or erroneous program > construct or of erroneous data, for which this International > Standard imposes no requirements > > Consequently, the C-standard 'imposes no requirements' upon the > behaviour of a conforming implementation when encountering a signal > handler which assigns a value to an int. And that's the end of the > story insofar the C-standard is concerned, which is, after all, > supposed to standardize (some aspects of) C implementations and not > programs written in C. An implementation might be 'broken' if it is > claimed that it would adhere to the C-standard but doesn't, but code > which produces "output dependent on any unspecified, undefined, or > implementation-defined behavior" is just "not maximally portable > among conforming implementations". Note, however, that other standards layered on top of C may impose implementation requirements that C by itself doesn't. So an undefined C program could be a well-defined POSIX program. And since this is comp.unix.programmer, not comp.lang.c, we shouldn't be overly concerned with portability beyond POSIX. His program is already not maximally portable because it uses fork() and kill(). -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: David Schwartz on 10 Feb 2010 11:44 On Feb 10, 8:02 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > Consequently, the C-standard 'imposes no requirements' upon the > behaviour of a conforming implementation when encountering a signal > handler which assigns a value to an int. And that's the end of the > story insofar the C-standard is concerned, which is, after all, > supposed to standardize (some aspects of) C implementations and not > programs written in C. An implementation might be 'broken' if it is > claimed that it would adhere to the C-standard but doesn't, but code > which produces "output dependent on any unspecified, undefined, or > implementation-defined behavior" is just "not maximally portable > among conforming implementations". All true, and none of which contradicts *anything* I said. *His* signal handler is broken, and it is broken *because* it breaks this rule. That is what I said. And that is true. You are correct that it would *also* be broken because it violates this rule if it claimed to be strictly-conforming. That would be another reason it would be broken for violating this rule. But I never said it was broken because it violated this rule and claimed to be strictly-conforming. That's a claim you made up just so that you could point out that it was wrong. DS
From: Jonathan de Boyne Pollard on 10 Feb 2010 15:50
> >>>> >>>> Because your signal handler is broken. >>>> > An implementation might be 'broken' if [...] > M. Schwartz didn't say that the implementation of the C language was broken. Xe said that the signal handler in the given program was broken, and then proceeded to explain how to fix the program. As xe has pointed out, you are making a lot of fuss over straw men. |