_POSIX_C_SOURCE=1 is invalid

[alarixnia]

Currently several programs set _POSIX_C_SOURCE to 1, e.g. aescrypt2. Going by some build errors I've seen, I think the description of "Harmless on other platforms." is incorrect.

The expected format for _POSIX_C_SOURCE is a date corresponding to a revision of the POSIX standard. A baseline for a library which requires C99 should be 200112L. Some strict platforms, e.g. Solaris, will refuse to compile as C99 if the standard is set to anything earlier.

See also #2310 - sockaddr_storage requires at least _XOPEN_SOURCE of 500.

Suggested fix: Set _POSIX_C_SOURCE to 200112L instead of 1.

[gilles-peskine-arm]

The expected value for _POSIX_C_SOURCE is a date now, but it wasn't a date originally. The Glibc manual has a handy table: 1 in 1990, 2 in 1992, then dates from 1993 onwards.

Mbed TLS is used on many embedded platforms that implement a subset of POSIX. So for us, portability is not just what's in POSIX. But it does include POSIX, so I think we should indeed use
200112L in the development branch.

LTS branches use C89 (plus a few extensions) so we should probably leave them alone.

We don't have Solaris or NetBSD on our CI, so a confirmation of what does and doesn't work would be welcome. Ideally with a known-good patch (that isn't at risk of breaking platforms that pretend to be POSIX but only implement a subset).

Though looking at why we're setting _POSIX_C_SOURCE to 1, it's only to include fileno, and in the sample programs fileno is only used to call lseek, and I don't see why that's needed at all: we should call fseek and ftell. In the test suite, it's used to redirect output to /dev/null, which doesn't seem very useful to me: it's something the caller can do if they want.

[danh-arm]

So it sounds like there's a possible enhancement task here to remove the dependency on _POSIX_C_SOURCE altogether but we can fix current definition in the meantime.