fails to build on freebsd due to _POSIX_C_SOURCE about tarsnap HOT 2 CLOSED

Thinking about this a bit more, I'm confused. I view "-D_POSIX_C_SOURCE" as saying "I need to use POSIX features, not just standard C features". But it seems that some people view "-D_POSIX_C_SOURCE" as saying "I promise that I'm not using anything other than POSIX"?

One point towards the "I promise I'm not using anything other than POSIX" is this:

When an application includes a header described by POSIX.1-2008, and when this feature test macro is defined to have the value 200809L:
...
Additional symbols not required or explicitly permitted by POSIX.1-2008 to be in that header shall not be made visible, except when enabled by another feature test macro.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_01_01

However, sys/mount.h isn't in POSIX, nor is statfs, so I guess this part of the spec doesn't apply?

I notice that I am confused.

from tarsnap.

So, _POSIX_C_SOURCE says "I claim that this code is strictly POSIX-compliant; make sure that you don't break it". In many cases this means "don't expose symbols which POSIX doesn't mention", since if (for example) an OS declares a function foobar but the strictly-POSIX-compliant program provides its own foobar, the incompatible declarations could break the build otherwise.

This does not apply in the case of headers which don't exist in POSIX, because if a program is trying to include those then it's lying about being strictly POSIX-compliant and so all guarantees are voided.

One possibility here would be to put #undef _POSIX_C_SOURCE at the top of the C files where we're using non-POSIX functionality; I'd hope that there aren't very many such files, but I'm not sure. Alternatively, compile libcperciva code with _POSIX_C_SOURCE set but omit it for libarchive-derived code?

from tarsnap.