[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210716160601.GD13220@brightrain.aerifal.cx>
Date: Fri, 16 Jul 2021 12:06:01 -0400
From: Rich Felker <dalias@...c.org>
To: John Scott <jscott@...teo.net>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] support the __STDC_WANT_LIB_EXT2__ feature test
macro
On Fri, Jul 16, 2021 at 11:58:47AM +0000, John Scott wrote:
> Hello,
>
> As a feature, I suggest that musl supports the __STDC_WANT_LIB_EXT2__
> feature test macro specified in the ISO/IEC Dynamic Allocations TR.
> I've attached a patch to accomplish this and which makes minimal
> changes to the headers to get musl's support comparable to glibc's.
>
> I was not able to get my hands on the official publication, so I only
> referred to the latest draft, which is available here:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1388.pdf
>
> I'm not subscribed, so please CC me on replies.
> From e923a4fc391909428914d3bebfb02b5431be338a Mon Sep 17 00:00:00 2001
> From: John Scott <jscott@...teo.net>
> Date: Fri, 16 Jul 2021 07:34:29 -0400
> Subject: [PATCH] support the __STDC_WANT_LIB_EXT2__ feature test macro
>
> this is intended to aid applications that wish to use the functionality
> specified in ISO/IEC TR 24731-2:2010. Most of these functions are
> specified by POSIX, except for (v)asprintf and some of the wide
> character functions.
>
> we don't define __STDC_ALLOC_LIB__ since the latter are not implemented.
> Also, implementations are required to diagnose when the definition of
> __STDC_WANT_LIB_EXT2__ changes after including additional headers, but
> we currently don't check this.
I'm not entirely against this, but I somewhat question both the
practical value (does anyone actually program to a "suppress POSIX but
want extensions from an unadopted C TR" profile?) and the potential
quagmire of getting bogged down in supporting a lot of TRs that never
make it into being an official part of the standard.
In particular we would need to be aware of any divergence between
these TRs and the corresponding specifications in POSIX; things would
get very messy if they disagree, since POSIX is aligned with ISO C but
*not* with random TRs. Moreover we don't even implement all of this TR
(the added wide functions you noted).
> ---
> include/stdio.h | 16 +++++++++++-----
> include/string.h | 9 +++++++--
> include/wchar.h | 7 ++++++-
> 3 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/include/stdio.h b/include/stdio.h
> index 3604198c..15687ba3 100644
> --- a/include/stdio.h
> +++ b/include/stdio.h
> @@ -131,9 +131,19 @@ FILE *tmpfile(void);
>
> #if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
> || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) \
> - || defined(_BSD_SOURCE)
> + || defined(_BSD_SOURCE) \
> + ||(defined(__STDC_WANT_LIB_EXT2__) && __STDC_WANT_LIB_EXT2__)
Small nit if this change is taken: the defined() condition isn't
needed and isn't doing anything here. Either way the default expansion
to 0 when it's not defined happens (because they're in the same #if)
and in any case musl is okay with using that part of the language.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
