How to Write Portable C Without Complicating Your Build

Re:How to Write Portable C Without Complicating Your Build by zuzun on Friday March 31, 2017 @07:02AM (#14002609)

There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. How do you check for headers? How do you check for functions? How do you test if qsort_r expects

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

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

as function pointer? If people are forced to detect that kind of stuff in Makefiles, they get the urge to match `uname` against some hard-coded platforms and that's a terrible solution.

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by coldtea on Friday March 31, 2017 @07:58AM (#14002859)

>There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself.

That's part of the argument: with standards compliant code, you don't need to do "what autotools does".

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by zuzun on Friday March 31, 2017 @11:30AM (#14004780)

ENOTSUP is part of the standard and I do have autotools macros checking if some function calls produce that error value on the host system.

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by zbuf on Friday March 31, 2017 @08:13AM (#14002922)

> no way you can do what autotools does in a Makefile

Well, you're responding to something that wasn't actually said; "these things" quotes specifically the list of requirements given by the previous poster -- CFLAGS etc.

Your example is indeed valid, it's an ugly case and I agree that testing for the feature specifically (rather than arch, compiler) is always preferred. But let's look at the practicalities -- how many of these cases do I actually need in a codebase to tip the balance that would justify use of autoconf? In your example, a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. qsort_r is off limits for massively portable program anyway, so autoconf's ability to help is limited anyway.

[ Parent | on HN ]

Re:How to Write Portable C Without Complicating Your Build by marcosdumay on Friday March 31, 2017 @01:05PM (#14005770)

> a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone.

That's equivalent to the uname trick the GP was complaining about. That means your software won't compile in a lot of platforms.

On a small scale, I don't think that's a big problem. Somebody on those platforms only has to add the correct conditions to your #ifdef forest and if he sends the update back, other people on the same platform won't even have the same problem. It's not much different from software not working on untested platforms.

It starts becoming a problem when done often, or on high level (at the calling stack) code.

[ Parent | on HN ]

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

> That means your software won't compile in a lot of platforms.

Is won't anyway; qsort_r has already limited me to a tiny number of platforms. If I care about further portability, autotools can't do anything to help me; my next step is not autotools, it's "don't use qsort_r"

[ Parent | on HN ]

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 ]