Bug in new K&R?

[Doug Gwyn]

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 ...

I believe the Committee agreed that our intent was not properly
expressed in the wording in the January 1988 draft, and that this is
being revised for the next draft so that the operands of this ?:
operator will have compatible types regardless of qualifiers.  (I
haven't seen the revised wording in context yet.)  I don't think that
there is a composite type assigned for the result of this function-
type meeting, though, which would be the real reason that a cast would
still be necessary.  I'm discussing this with the draft Redactor.  (So
far he says that char * and void * are not compatible types, just
assignment compatible, to which my response is that given the identity
of representation that seems like an oversight.)

>In our defense, given that the representation of char* is the same
>as that of void*, it is reasonable to expect that you would be safe
>in reproducing the book example provided your compiler accepted it.
>However, at least as I read the last-issued version of the standard,
>the compiler might well reject it.

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.