signals == software interrupts ?
in [Unix Programming]
|
From: Jonathan de Boyne Pollard on 13 Feb 2010 03:19 > > > The C-standard only uses the term 'broken' as part of the term > 'broken-down time'. > M. Schwartz tells someone that xyr program is broken, and shows how to fix it; and you go and look for the word "broken" in the C standard to see what it means? Come on! I don't believe that. You're being obtuse deliberately, and I claim my five pounds.
From: pk on 13 Feb 2010 08:07 Jonathan de Boyne Pollard wrote: >> The C-standard only uses the term 'broken' as part of the term >> 'broken-down time'. >> > M. Schwartz tells someone that xyr program is broken, and shows how to > fix it; and you go and look for the word "broken" in the C standard to > see what it means? Come on! I don't believe that. You're being obtuse > deliberately, and I claim my five pounds. I fear it's not deliberate. PS: I plonked him a long time ago.
From: Andreas H on 13 Feb 2010 13:05 "David Schwartz" <davids(a)webmaster.com> wrote: > *this* code was broken *because* it violated a rule in the C standard I think that's flat wrong. The original code obviously was "broken" because it didn't work as intended. But why did it fail? Only because of not strictly conforming to the standard? No, of course not, because the standard leaves its behavior undefined in that case. Thus, this code was broken because it relied on a *non-standard behaviour* that was not supported by the actual implementation. I generally enjoy reading your postings in this group, but you really should not call somebody an idiot just like that, please. Andreas
From: Rainer Weikusat on 14 Feb 2010 10:35 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups(a)NTLWorld.COM> writes: >> The C-standard only uses the term 'broken' as part of the term >> broken-down time'. >> > M. Schwartz tells someone that xyr program is broken, and shows how to > fix it; and you go and look for the word "broken" in the C standard to > see what it means? Come on! I don't believe that. You're being > obtuse deliberately, and I claim my five pounds. Sorry, but this is (IMHO) an important topic (for users of C). "The C-standard leaves the behaviour undefined' means just that. A conforming implementation is thus free to do (or not do) anything the implementer considered sensible and this includes *anything useful*. A prominent example would be 'malloc' which is an ordinary library routine at least on UNIX(*) and uses 'some kernel-provided allocation primitives' (brk, mmap). A malloc-implementation written in C has 'undefined behaviour', insofar the C-standard is concerned, from start to finish and the same is true for every program which uses any of the memory management facilities the kernel provides, including using shared memory for IPC. Also, sig_atomic_t is required to be a typedef name and this means, an alias for another type. In the case at hand, this is 'int' and hence, on systems using glibc, and presumably on a lot of others, 'int' is exactly as good as sig_atomic_t for signal handlers. Using it limits the portability of the code to implementations with similar properties but this is not an error in itself.
From: David Schwartz on 14 Feb 2010 12:15
On Feb 13, 10:05 am, "Andreas H" <Andreas.H....(a)alumni.tu-berlin.de> wrote: > "David Schwartz" <dav...(a)webmaster.com> wrote: > > *this* code was broken *because* it violated a rule in the C standard > I think that's flat wrong. Then please explain why. > The original code obviously was "broken" because it didn't work as intended. > But why did it fail? Only because of not strictly conforming to the > standard? No, of course not, because the standard leaves its behavior > undefined in that case. I didn't say it was *only* broken because it violated a rule in the C standard. You are doing the same thing Rainer is doing, making your own version of my argument just to show it's wrong. If someone falls asleep with a cigarette in their mouth is it wrong to say "the fire happened because the person fell asleep with a cigarette in their mouth"? Is it sensible to say, "no, it didn't only happen because the person fell asleep with a cigarette in their mouth, that only caused a fire because the bed was combustible. That is obvious idiocy. It is not incorrect to point out that there would not have been a fire had the bed been made out of stone. But it is idiocy to argue this somehow contradicts the argument that the fire occured *because* the person was smoking in bed. > Thus, this code was broken because it relied on a *non-standard behaviour* > that was not supported by the actual implementation. That is another way to say the exact same thing I said. > I generally enjoy reading your postings in this group, but you really should > not call somebody an idiot just like that, please. Believe me, I'm quite careful before I throw term that around. DS |