Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!killer!tness7!bellcore!spectral!sjs From: sjs@spectral.ctt.bellcore.com (Stan Switzer) Newsgroups: comp.lang.c Subject: Re: Bug in new K&R? Message-ID: <7288@bellcore.bellcore.com> Date: 10 May 88 19:08:11 GMT References: <7861@alice.UUCP> <7860@brl-smoke.ARPA> Sender: news@bellcore.bellcore.com Reply-To: sjs@spectral.UUCP (Stan Switzer) Organization: Bellcore Lines: 50 In article <7861@alice.UUCP> dmr@alice.UUCP writes: > qsort((void **) lineptr, 0, nlines-1, > (int (*)(void*,void*))(numeric ? numcmp : strcmp)); > > The relevant question is whether the two arms of the conditional are > `pointers to compatible types,' and the answer, I'm afraid, is no, > because the parameters are not identically qualified ... And after a good bit of exposition concludes that many people will be surprised at the number of different languages recognized (and rejected) by "conforming" C compilers. In defense of ANSI, gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) writes: > Yes, that is the essential question. If it makes it through the > compiler, I think it is guaranteed to work, but we need to know > whether it is guaranteed to make it through the compiler without > a possibly fatal diagnostic. > > Personally I wouldn't have tried writing code that explores the dark > corners of the language like that but would have made my comparison > function arguments have precisely the same type as qsort expects, > with (trivial) conversion at the beginning of the comparison function. > I know THAT is supposed to work portably. To this I can only ask: "Why are there STILL dark corners?" I know unambiguous specification is dark art (and formal approaches have been none too successful), but it really isn't fair to defend a standard by calling a reasonable construction a "dark corner" of the language. Basically, I recognize the need for a C standard, and I sympathize that one should avoid "obscure" constructions (a judgement call in any case), but I can't help but be nostalgic for the days when "pcc" itself was the "standard" against which C compilers were compared (syntacticly speaking) and when the only sensible measure of a C compiler other than recognizing pcc's language was that it ran code that ran on VAXes (modulo byte order and char signedness). As a cautious customer, I have learned to interpret specfications perversely in order to anticipate the worst case implementations. It would be fun to postulate perverse but conforming interpretations of the ANSI C language. Perhaps a contest is in order. This is no small concern, because as C expands into new markets and environments, there is good reason to fear that a lot of houey will be sold under the banner "standard conforming" and we might very well find ourselves living with a new and unfortunate mutatation of "C". I know all about the "quality-of- implementation" argument, and I am not impressed: just look how many people think "char *far foo;" is proper C. Stan Switzer