Do not add feature test macros

[zeehio]

On b4c1548 (see #5) I proposed defining _POSIX_C_SOURCE inside cutest.h in order to enable the macros to use POSIX under unix-like systems, as POSIX was used by cutest on those systems.

Here I propose to follow whatever the user wants. This means:

• If the user explicitly defines a strict standard C compliance (e.g. compiling using --std=c99) then we do not use any POSIX feature. This is detected through the definition of the STRICT_ANSI macro.

• If the user does not enforce any C standard, we assume POSIX is available if the system is unix-like, as before.

I believe this approach is better than the previous one because if any cutest user does not want to rely on POSIX features we won't enable them and we won't use them. However by default we use them if they are available.

[mity]

Hi @zeehio ,

to be honest, I was thinking quite a lot before I merged the referred #5, because I disliked how the #define _POSIX_SOURCE could potentially interfere with other macros from outside (i.e. predefined by compiler command line). Furthermore I think the macro is from Linux/gcc world and many other Unix systems do not recognize it.

The current PR makes this even worse in my eyes: It makes quite a hybrid animal from cutest.h which sometimes tries to detect the predefined macros from outside and follow them and sometimes (pre)define some macro before including the system headers to change their behavior.

I would therefore highly prefer if we could unify on strictly following the environment and never setting such macro manually in the header, if that's possible.

Furthermore, as it is implemented, it also seems to change the default run-time behavior in other ways. In particular, not using fork() for the unit tests. I don't think we should interpret gcc -std=c99 as "do not use any POSIX", because it is often meant (and I believe rightfully) to just "disable GNU C extensions".

So my counter-proposal is as follows (and please let me know if it would satisfy your needs):

0. As Linux is of course very important to support well, we should have a policy to be buildable with any options specifying C standard (newer then C90, as that really is too old, and it even lacks vsnprintf(). C89/90 simply is not supported), and that cutest.h strictly follows the environment, but does not try to set it.

1. Remove the enforcing of _POSIX_C_SOURCE (i.e. revert POSIX fixes for standard C compatibility #5).

2. Remove the use of fileno(stdout) and replace it with STDOUT_FILENO from <unistd.h> (or constant 1, if we find some relevant systems do not have the macro). (The fileno() is likely the only thing which was behind POSIX fixes for standard C compatibility #5, right?)

3. Not accept this PR as it should not be needed anymore.

Would this work for you?

[zeehio]

Your proposal is much better than mine.

I have updated the PR with your instructions, so you don't have to type more if you don't want to. I have given you too much work already. 😅 But feel free to do the commit yourself if you prefer.

By the way, I also disabled the test_error__ function if it is not used. When neither CUTEST_WIN__ nor CUTEST_UNIX__ are defined a "warning: unused function test_error__" appeared.

Thanks for your careful thoughts and detailed explanation.

[mity]

For Windows, _isatty(_fileno(stdout)) should be kept. Windows SDK does not have <unistd.h>

[zeehio]

Thanks for the review. Done.

[mity]

Thanks, @zeehio