How to Write Portable C Without Complicating Your Build

Re:How to Write Portable C Without Complicating Your Build by maxlybbert on Friday March 31, 2017 @09:32AM (#14003540)

> How do you test if qsort_r expects

    > (*)(void*, const void*, const void*)

> or

    > (*)(const void*, const void*, void*)

You can write C++ code that uses templates and SFINAE to do it. I have. I will admit, it looks like garbage. But it is possible.

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by jandrese on Friday March 31, 2017 @12:13PM (#14005227)

Who uses the latter form? I don't think I've ever seen that before.

Also, isn't the first supposed to be:

  void*, size_t, size_t, int (*cmp)(const void*, const void*)

Or are you using some wtf version that hides the element size and count behind a void*?

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by maxlybbert on Friday March 31, 2017 @12:51PM (#14005634)

The signatures came from another answer. I have no idea what the signatures are, or should be, or why there's a difference.

My SFINAE code was to handle a similar problem picking between a GNU-specific strerror_r and a POSIX strerror_r that have different signatures (both are available on Linux, determined by whether certain macros are set: https://linux.die.net/man/3/strerror_r , I couldn't just rely on those macros because I wanted my code to compile on any POSIX platform).

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by zbuf on Friday March 31, 2017 @02:19PM (#14006483)

You're commenting on the prototype for qsort() itself, whereas the original point was about the function pointer that is an argument to qsort_r().

Both Linux and BSD chose to add a non-standard qsort_r(), each choosing different ways to do it.

[ Parent | on HN ]