[pistoleer]

It's worse than that. This guy takes a void* function and casts it to a char* function, then passes it a char**.

    void (*name)(char *ptr);
    typedef void (*name_func)(char *ptr);

    void target(void *ptr)
    {
       printf("Input %p\n", ptr);
    }


    char *data = "string";
    name = (name_func)target; // Illegal: casting fn that takes void* to a fn that takes char*
    name(&data); // Illegal: passing a char** into a function that takes char*

Before someone mentions qsort(): the comparator function really is supposed to take a void*, and inside the function, you re-cast the void* argument to a pointer type of your desire. If you don't do it in that order, you're using it wrong.

[trealira]

Ironically, in K&R, they did exactly this for casting comparator functions for their own version of qsort.

  /* declarations */
  void qsort(void *lineptr[], int left, int right,
             int (*comp)(void *, void *));
  int numcmp(char *, char *);

  /* the offending line */
  qsort((void **) lineptr, 0, nlines-1, 
    (int (*)(void*,void*)(numeric ? numcmp : strcmp));

[layer8]

The C standard mandates that a “pointer to void shall have the same representation and alignment requirements as a pointer to a character type”. In consequence, the same holds for an array of void pointers vs. an array of char pointers. The code therefore seems valid to me, and furthermore at no point is a function called with an argument type different from its formal parameters.

In the GP example, a char** is passed where a char* is expected. That is clearly invalid.

[trealira]

I was more referring to how, in the K&R example, a function of type "int (*)(char *, char *)" is cast to "int (*)(void *, void *)", in contradiction to what they said here:

> Before someone mentions qsort(): the comparator function really is supposed to take a void*, and inside the function, you re-cast the void* argument to a pointer type of your desire. If you don't do it in that order, you're using it wrong.

In contrast, the K&R example is an example of explicitly undefined behavior in the C standard:

The behavior is undefined in the following circumstances:

- A pointer is used to call a function whose type is not compatible with the pointed-to type (6.3.2.3).

[Someone]

> the K&R example is an example of explicitly undefined behavior in the C standard

You can’t blame K&R C for that. It predates “the C standard” by over a decade (1978 vs 1989)

When it was written, what K&R said was C.

[trealira]

The second edition was released in 1988, and it was based on a draft of the first ANSI C standard, and even then, the line stating that this was undefined behavior was already present.

http://jfxpt.com/library/c89-draft.html#A.6.2

> A pointer to a function is converted to point to a function of a different type and used to call a function of a type not compatible with the original type (3.3.4).

[layer8]

The example is still the same in the second edition of K&R, which is based on C89.

[layer8]

Ah, I missed that. However, footnote 41 states “The same representation and alignment requirements are meant to imply interchangeability as arguments to functions […]”, which could be taken as implying compatibility of function types, though the normative wording doesn’t directly support that.

[trealira]

Good point. It would be nice if the C standard were slightly clearer here.

[rom1v]

> name(&data); // Illegal: passing a char* into a function that takes char*

I assume this is just a typo in the article. He probably meant `name(data)`.