Bug in new K&R?

[Stan Switzer]

In article <7861 at alice.UUCP> dmr at 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 at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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