signals == software interrupts ?
in [Unix Programming]
|
From: Jonathan de Boyne Pollard on 12 Feb 2010 05:02 > >>>>>> >>>>>> 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. >> > And you didn't read my text. > M. Schwartz and I have both read your text, and are both telling you that you are repeatedly constructing straw men. The fact that at least two people following the discussion are independently telling you this should be telling you something.
From: Rainer Weikusat on 12 Feb 2010 07:53 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. . 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. >>> >> And you didn't read my text. >> > M. Schwartz and I have both read your text, and are both telling you > that you are repeatedly constructing straw men. Are you sure that you understand the term 'straw man'? This refers to constructing mock arguments in favor of a position one wants to argue against and then shooting those down using 'strategically' embedded weaknesses. I would very much like to have something like an intelligible explanation how I am supposed to have done this, at best based on a fraction of text I wrote which is large enough to still communicate the intended meaning. > The fact that at least two people following the discussion are > independently telling you this should be telling you something. It communicates that at least two people are confused about the C-standard. But 'being confused about the C-standard' is something a lot of people practice passionately. So that's not really news.
From: David Schwartz on 12 Feb 2010 17:01 On Feb 12, 4:53 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > > M. Schwartz and I have both read your text, and are both telling you > > that you are repeatedly constructing straw men. > Are you sure that you understand the term 'straw man'? This refers to > constructing mock arguments in favor of a position one wants to argue > against and then shooting those down using 'strategically' embedded > weaknesses. I would very much like to have something like an > intelligible explanation how I am supposed to have done this, at best > based on a fraction of text I wrote which is large enough to still > communicate the intended meaning. That is *precisely* what you are doing, over and over again. For example: "This except doesn't support the notion that 'the signal handler is broken'. 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). 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'. " You deliberately responded to the correct and sensible argument that *this* code was broken *because* it violated a rule in the C standard as if it were the (obviously nonsensical) argument that all code that is not strictly-conforming to the C standard is "broken". DS
From: Rainer Weikusat on 12 Feb 2010 17:42 David Schwartz <davids(a)webmaster.com> writes: > On Feb 12, 4:53�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > >> > M. Schwartz and I have both read your text, and are both telling you >> > that you are repeatedly constructing straw men. > >> Are you sure that you understand the term 'straw man'? This refers to >> constructing mock arguments in favor of a position one wants to argue >> against and then shooting those down using 'strategically' embedded >> weaknesses. I would very much like to have something like an >> intelligible explanation how I am supposed to have done this, at best >> based on a fraction of text I wrote which is large enough to still >> communicate the intended meaning. > > That is *precisely* what you are doing, over and over again. Nope. > For example: > > "This except doesn't support the notion that 'the signal handler is > broken'. 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). 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'. " > > You deliberately responded to the correct and sensible argument that > *this* code was broken *because* it violated a rule in the C > standard The C-standard only uses the term 'broken' as part of the term 'broken-down time'. I figure that's not what you were writing about. According to the C-standard and the specifics of the situation, the code is 'conforming C' (since it is acceptable to a conforming implementation) and not 'strictly conforming C' (because it produces output dependent on implementation behaviour in a situation for which the C-standard 'makes no requirements', aka leaves the behaviour undefined). And that's everything definite the C-standard says on the topic of 'undefined behaviour'. Any statement beyond 'not strictly conforming C' is a statement about topics beyond the scope of the C language definition and hence, needs to be based on something else than the absence of information about topics beyond the C language definition in the C language definition.
From: David Schwartz on 12 Feb 2010 17:53
On Feb 12, 2:42 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > The C-standard only uses the term 'broken' as part of the term > 'broken-down time'. I figure that's not what you were writing about. > According to the C-standard and the specifics of the situation, the > code is 'conforming C' (since it is acceptable to a conforming > implementation) and not 'strictly conforming C' (because it produces > output dependent on implementation behaviour in a situation for which > the C-standard 'makes no requirements', aka leaves the behaviour > undefined). And that's everything definite the C-standard says on the > topic of 'undefined behaviour'. Any statement beyond 'not strictly > conforming C' is a statement about topics beyond the scope of the C > language definition and hence, needs to be based on something else > than the absence of information about topics beyond the C language > definition in the C language definition. You are being an idiot. I've tried patiently to point that out to you, but now I give up. "[W]hat you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it." DS |