signals == software interrupts ?
in [Unix Programming]
|
From: Nicolas George on 14 Feb 2010 16:38 Golden California Girls wrote in message <hl9p04$83u$1(a)speranza.aioe.org>: > Does a failure to so state indicate he wasn't? Yes, since he is posting in a group dedicated to Unix in general and not a particular implementation.
From: Andreas H on 14 Feb 2010 19:24 "David Schwartz" <dav...(a)webmaster.com> wrote: > 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. I rather was trying to give you a feedback on my personal understanding of your argumentation. Anyway - I think I got your point by now. >> 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. Well, I agree - even though this is of course not _formally_ equivalent to your original statement, that included an unconditional logical implication between "violating the C standard" and "being broken". Andreas
From: Ben Bacarisse on 14 Feb 2010 22:09 Rainer Weikusat <rweikusat(a)mssgmbh.com> writes: > 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. I don't think that is enough on its own. Surely an implementation is permitted to special-case variables of type sig_atomic_t? In other words, to say that int is exactly as good as sig_atomic_t you need to know not only that sig_atomic_t is an alias for int but also that the implementation does nothing special with it. > Using it limits > the portability of the code to implementations with similar properties > but this is not an error in itself. -- Ben.
From: Rainer Weikusat on 15 Feb 2010 05:38 Ben Bacarisse <ben.usenet(a)bsb.me.uk> writes: > Rainer Weikusat <rweikusat(a)mssgmbh.com> writes: [...] >> 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. > > I don't think that is enough on its own. Surely an implementation is > permitted to special-case variables of type sig_atomic_t? A type 'sig_atomic_t' does not exist. But there is actually a better 'attack vector' for this type of misinterpretation, because the sig_atomic_t definition only says that the type is to be defined by a particular header, and, of course, this makes the assertion that 'defining a type' is not necessarily anyhow related to typedef one the text doesn't explicitly contradict. But complete newsgroups solely dedicated to the creative misinterpretation of the C-standard actually exist and discussions of this 'topic' should rather happen there, since the practical relevance of these type of intellectual exercises is generally zero. IOW, theoretically, you're statement is AFAIK irrefutable, and practically, unless I have to use such an implementation, which I don't believe to exist (information to the contrary welceom), I simply don't care and would recommend this more hands-on approach to others as well.
From: Nicolas George on 15 Feb 2010 11:12
Golden California Girls wrote in message <hlaaq1$1lr$1(a)speranza.aioe.org>: <snip> Excuse-me, I assumed that you were interested in technical discussion, while you are obviously only interested in cheap trolls. And by the way, you have a spelling problem: assume does not have hyphens. |