Re: 'Proper' software writing

[Rich Felker <dalias@aerifal.cx>]

On Mon, Sep 03, 2012 at 03:55:47PM +0200, Igmar Palsenberg wrote:
> Hi,
> 
> When attempting to fix my own piece of software I've come to the
> conclusing that writing somewhat portable software (glibc vs musl) is a
> huge PITA.

Yes. Actually it's also a huge PITA between other implementations too,
but the breakage is all a lot more subtle. Basically the surest way to
write portable software is to use _POSIX_C_SOURCE or _XOPEN_SOURCE and
write purely to the standards, not using any extension functionality,
but often you want or even need at least some extensions that are
pretty much universally available, and then there's no well-defined
way to get them...

> - Why use _BSD_SOURCE and _GNU_SOURCE at all ? What is the argument of
> not exposing *ALL* stuff that is in musl ?

All is probably too much; there's a lot of ugly cruft (like lowercase
macros named major and minor getting exposed whenever you include
stdlib.h) in the "expose it all" _GNU_SOURCE profile. This is bad
enough if you're requesting it, but really bad if it's just there by
default.

I'm well aware that your frustration is the first/biggest FAQ people
have when trying to use musl and that it's a bad first experience.
Right now there's a big ongoing thread about what to do about it, and
we're doing some research on applications and the headers themselves
to figure out what a sane, clean, default profile to expose would be.

> - Is there a way to do proper feature detection ? I tried autoscan from
> autotools, but the outcome wanted to make me cry. It missed about all
>    that is important.

Gregor has a really good guide to using autotools properly, and some
tricks to make generated autoconf scripts lighter/faster by
dummying-out useless ones:

https://bitbucket.org/GregorR/autoconf-lean

Rich