Keith Thompson wrote:
The complete errata from http://tinyurl.com/3nbvbh :
"119-121(§5.11): The qsort discussion needs recasting in several ways.
First, qsort is a standard routine in ANSI/ISO C, so the rendition here
should be given a different name, especially because the arguments to
standard qsort are a bit different: the standard accepts a base pointer
and a count, while this example uses a base pointer and two offsets".
Because of this I renamed the "qsort" references, declarations and
definitions as "sort".
"Also, the comparison-routine argument is not treated well. The call
shown on p 119, with an argument
(int (*)(void*,void* ))(numeric? numcmp : strcmp)
is not only complicated, but only barely passes muster. Both numcmp and
strcmp take char * arguments, but this expression casts pointers to
these functions to a function pointer that takes void * arguments. The
standard does say that void * and char * have the same representation,
so the example will almost certainly work in practice, and is at least
defensible under the standard. There are too many lessons in these pages."
So, what can be a reasonable fix for this mistake in K&R2? On page 119,
changing the function signature of sort (renamed sort from qsort as
mentioned above) taking as an argument "int (*comp)(void *, void *)" to
take as an argument int (*comp)(char *, char *) above the main()
definition, and remove the cast in main()?
I should expect Kernighan & Ritchie to provide more complete errata for
K&R2, than these.
Ioannis Vranos <ivranos@nospam .no.spamfreemai l.grwrites:
>
Yes, but it doesn't guarantee that a pointer to a function with void*
parameters is compatible with a pointer to a function with char*
parameters. It would take a perverse implementation for the cast
above to fail, but the standard doesn't guarantee that it will work.
>
In general, the only guarantees regarding a conversion from one
pointer-to-function type to another ar that it doesn't lose
information and that converting it back to the original type gives you
a usable pointer.
>C90:
>From the K&R2 errata site: http://tinyurl.com/3nbvbh
>>
>1.
>>
>"...
>Also, the comparison-routine argument is not treated well. The call
>shown on p 119, with an argument
>>
> (int (*)(void*,void* ))(numeric? numcmp : strcmp)
>>
>is not only complicated, but only barely passes muster. Both numcmp and
>strcmp take char * arguments, but this expression casts pointers to
>these functions to a function pointer that takes void * arguments.
>>
>==The standard does say that void * and char * have the same
>representation , so the example will almost certainly work in practice,
>and is at least defensible under the standard. There are too many
>lessons in these pages".
>>
>>
>Does the C90 standard guarantee that "void * and char * have the same
>representation "?
>From the K&R2 errata site: http://tinyurl.com/3nbvbh
>>
>1.
>>
>"...
>Also, the comparison-routine argument is not treated well. The call
>shown on p 119, with an argument
>>
> (int (*)(void*,void* ))(numeric? numcmp : strcmp)
>>
>is not only complicated, but only barely passes muster. Both numcmp and
>strcmp take char * arguments, but this expression casts pointers to
>these functions to a function pointer that takes void * arguments.
>>
>==The standard does say that void * and char * have the same
>representation , so the example will almost certainly work in practice,
>and is at least defensible under the standard. There are too many
>lessons in these pages".
>>
>>
>Does the C90 standard guarantee that "void * and char * have the same
>representation "?
Yes, but it doesn't guarantee that a pointer to a function with void*
parameters is compatible with a pointer to a function with char*
parameters. It would take a perverse implementation for the cast
above to fail, but the standard doesn't guarantee that it will work.
>
In general, the only guarantees regarding a conversion from one
pointer-to-function type to another ar that it doesn't lose
information and that converting it back to the original type gives you
a usable pointer.
The complete errata from http://tinyurl.com/3nbvbh :
"119-121(§5.11): The qsort discussion needs recasting in several ways.
First, qsort is a standard routine in ANSI/ISO C, so the rendition here
should be given a different name, especially because the arguments to
standard qsort are a bit different: the standard accepts a base pointer
and a count, while this example uses a base pointer and two offsets".
Because of this I renamed the "qsort" references, declarations and
definitions as "sort".
"Also, the comparison-routine argument is not treated well. The call
shown on p 119, with an argument
(int (*)(void*,void* ))(numeric? numcmp : strcmp)
is not only complicated, but only barely passes muster. Both numcmp and
strcmp take char * arguments, but this expression casts pointers to
these functions to a function pointer that takes void * arguments. The
standard does say that void * and char * have the same representation,
so the example will almost certainly work in practice, and is at least
defensible under the standard. There are too many lessons in these pages."
So, what can be a reasonable fix for this mistake in K&R2? On page 119,
changing the function signature of sort (renamed sort from qsort as
mentioned above) taking as an argument "int (*comp)(void *, void *)" to
take as an argument int (*comp)(char *, char *) above the main()
definition, and remove the cast in main()?
I should expect Kernighan & Ritchie to provide more complete errata for
K&R2, than these.