signals == software interrupts ?
in [Unix Programming]
|
From: Rainer Weikusat on 11 Feb 2010 05:30 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups(a)NTLWorld.COM> writes: >> >>>>> >>>>> 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. And you didn't read my text.
From: Rainer Weikusat on 11 Feb 2010 05:39 David Schwartz <davids(a)webmaster.com> writes: > 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. This is not true. The code exploits implementation-specific behaviour not defined by the C-standard and hence, it is not 'strictly conforming'. Since it is acceptable to a conforming implementation, it is 'conforming C'. The C-standard calls this (as quoted above) 'not maximally portable among conforming implementations' and that's something rather different from 'broken'.
From: David Schwartz on 11 Feb 2010 09:50 On Feb 11, 2:39 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > *His* signal handler is broken, and it is broken *because* it breaks > > this rule. That is what I said. And that is true. > This is not true. The code exploits implementation-specific behaviour > not defined by the C-standard and hence, it is not 'strictly > conforming'. Since it is acceptable to a conforming implementation, it > is 'conforming C'. The C-standard calls this (as quoted above) 'not > maximally portable among conforming implementations' and that's > something rather different from 'broken'. Again, all true, and none of which contradicts what I said. His code is broken. It is broken because it violates this rule. You have come with yet another way in which it is not broken, and I agree, it is not broken every possible way. It is not even broken every possible way it could be broken because of violating this rule. And if he modified his code to comply with this rule, it would work the way he intended. As it is, it doesn't work on his platform specifically because it violates this rule. DS
From: Rainer Weikusat on 11 Feb 2010 10:20 David Schwartz <davids(a)webmaster.com> writes: > On Feb 11, 2:39�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > >> > *His* signal handler is broken, and it is broken *because* it breaks >> > this rule. That is what I said. And that is true. > >> This is not true. The code exploits implementation-specific behaviour >> not defined by the C-standard and hence, it is not 'strictly >> conforming'. Since it is acceptable to a conforming implementation, it >> is 'conforming C'. The C-standard calls this (as quoted above) 'not >> maximally portable among conforming implementations' and that's >> something rather different from 'broken'. > > Again, all true, and none of which contradicts what I said. It has so far contradicted your "this code is broken" statement each and every time. The code is not "broken" just because it isn't 'strictly conforming C'. That's a misinterpretation of the C-standard certain people like to spread. [...] > And if he modified his code to comply with this rule, it would work > the way he intended. As it is, it doesn't work on his platform > specifically because it violates this rule. It didn't work on 'his platform' (which, for practical purposes, is equivalent to all platforms glibc was ever ported to and all POSIX systems the glibc maintainer(s) had ever heard of) because of the missing volatile and this didn't "invoke the wrath of the gods" because of some random statement about signal handlers in the C-standard but specifically allowed the compiler to assume that one read of the value stored in the object would be as good as twenty reads, provided that no code modifying the object was possibly reachable by 'ordinary' control flow (as in while (RUN);). The purpose of volatile is to assert that "it is not so" in such cases. Reading the value in the object should be considered to cause 'necessary side effects' to happen and hence, when the code say 'if (RUN == 0);' twenty times in a row, the content of the memory location the object resides at is to be checked each time. Since glibc does typedef int sig_atomic_t sig_atomic_t is an *A*L*I*A*S* for int on this platform and one can always be used in place of the other.
From: David Schwartz on 11 Feb 2010 12:05
On Feb 11, 7:20 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > Again, all true, and none of which contradicts what I said. > It has so far contradicted your "this code is broken" statement each > and every time. No, you haven't. You've simply made an argument I didn't make and then showed that argument to be incorrect. > The code is not "broken" just because it isn't > 'strictly conforming C'. I agree. > That's a misinterpretation of the C-standard > certain people like to spread. Perhaps. > > And if he modified his code to comply with this rule, it would work > > the way he intended. As it is, it doesn't work on his platform > > specifically because it violates this rule. > It didn't work on 'his platform' (which, for practical purposes, is > equivalent to all platforms glibc was ever ported to and all POSIX > systems the glibc maintainer(s) had ever heard of) because of the > missing volatile and this didn't "invoke the wrath of the gods" > because of some random statement about signal handlers in the > C-standard but specifically allowed the compiler to assume that one > read of the value stored in the object would be as good as twenty > reads, provided that no code modifying the object was possibly > reachable by 'ordinary' control flow (as in while (RUN);). The purpose > of volatile is to assert that "it is not so" in such cases. Reading > the value in the object should be considered to cause 'necessary side > effects' to happen and hence, when the code say 'if (RUN == 0);' twenty > times in a row, the content of the memory location the object resides > at is to be checked each time. True, but the whole reason for standards is so that people don't have to worry about what optimizations different compilers might do or not do. > Since glibc does > > typedef int sig_atomic_t > > sig_atomic_t is an *A*L*I*A*S* for int on this platform and one can > always be used in place of the other. So what? What does that have to do with what I said? I never said there was no way he could write his code such that it would still violate that part of the standard and not be broken. I said that: 1) His code is broken. 2) It is broken because it violates that section of the standard. I did not say "all code that violates that section of the standard is broken". I said *his* code is broken *because* it violates that part of the standard. You are quite correct that he could fix his code while still having it violate that section of the standard. But I never denied that. DS |