Re: [dev] [edit] Introducing edit, a simple text editor

2023-09-28 Thread Страхиња Радић
On 23/09/28 09:02AM, David Demelier wrote:
> Not sure if that helps but I eventually stopped adding flags at all and
> use just the defaults everywhere. Otherwise I'd be glad to understand
> if there is a complete and strict conformance explanation on those
> combinations.

As Adam noted, the macros need to be defined before including the headers. More 
details can be found in feature_test_macros(7)[1] and libc documentation.


musl libc documentation[2] states (search for "Feature Test Macros Supported by 
musl")
> If no feature test macros are defined, musl's headers operate in
> "default features" mode, exposing the equivalent of the `_BSD_SOURCE`
> option below. This corresponds fairly well to what most applications
> unaware of feature test macros expect, and also provides a number of
> more modern features.
> 
> Otherwise, if at least one of the below-listed feature test macros is
> defined, they are treated additively, starting from pure ISO C as a
> base. Unless otherwise specified, musl ignores the value of the macro
> and only checks whether it is defined.


Likewise, glibc documentation[3] on feature test macros states:
> Be aware that compiler options also affect included features:
> 
> * If you use a strict conformance option, features beyond those from the 
>   compiler’s language version will be disabled, though feature test macros 
>   may be used to enable them.
> * Features enabled by compiler options are not overridden by feature test 
>   macros.


It is worth noting that most suckless programs don't define feature test macros 
inside of the source code. Instead, they are usually specified in config.mk as 
command line arguments passed to the compiler (thus guaranteed to not suffer 
from header inclusion before defining feature test macros). This also gives a 
clue on how to use termbox2.h properly.


Also: https://suckless.org/coding_style/
> C Features
> 
> * Use C99 without extensions (ISO/IEC 9899:1999).
> * Use POSIX.1-2008:
>   - When using gcc define _POSIX_C_SOURCE 200809L.
>   - Alternatively define _XOPEN_SOURCE 700.


[1]: https://linux.die.net/man/7/feature_test_macros
[2]: https://musl.libc.org/doc/1.1.24/manual.html
[3]: 
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fDEFAULT_005fSOURCE



signature.asc
Description: PGP signature


Re: [dev] [edit] Introducing edit, a simple text editor

2023-09-28 Thread David Demelier
On Wed, 2023-09-27 at 22:33 +0200, Страхиња Радић wrote:
> On closer inspection, termbox2.h does include signal.h itself[1], and
> additionally defines _XOPEN_SOURCE[2] and _DEFAULT_SOURCE, so the
> inclusion of 
> signal.h can't be escaped.
> 
> My testing has shown that when -std=c99 is specified, it is as if
> that switch 
> explicitly undefines _DEFAULT_SOURCE/_XOPEN_SOURCE **defined inside
> the header 
> file** (this is the weird part). If -D_DEFAULT_SOURCE is given as an
> argument, 

This,

I've been played several times with -std and
_POSIX_C_SOURCE/_XOPEN_SOURCE and experienced many different behavior
depending on the system and libc. Example, I remember that setting
_XOPEN_SOURCE could hide non-standard functions which can still be
useful as long as you take care of the proper #define.

Not sure if that helps but I eventually stopped adding flags at all and
use just the defaults everywhere. Otherwise I'd be glad to understand
if there is a complete and strict conformance explanation on those
combinations.

-- 
David