[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFhhQJQu4o++-U2ocFC5i24rgPMsstOUx7SBPKRUK61gDY-5Aw@mail.gmail.com>
Date: Thu, 20 Oct 2016 19:19:50 -0400
From: Daniel Sabogal <dsabogalcc@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Header conformance/improvements
On Thu, Oct 20, 2016 at 5:30 PM, Rich Felker <dalias@...c.org> wrote:
> On Tue, Oct 11, 2016 at 06:44:14PM -0400, Daniel Sabogal wrote:
>> namespace/feature testing
>> -------------------------
>> sys/time.h:13-29: sys/time.h - XSI header
>
> Not sure what you mean here. If the whole header is XSI there's no
> obligation to check FTMs; a conforming non-XSI program doesn't include
> it.
Sorry, I should have been more descriptive with this one. The issue here is
that there are unnecessary checks for _XOPEN_SOURCE.
>> misc
>> ----
>> stdlib.h:155-8:
>> glibc provides locale_t under _GNU_SOURCE. maybe it should
>> be provided and used in place of struct __locale_struct.
>
> Do you have in mind a scenario where this would be useful, i.e. where
> you might need locale_t to be defined but not have included another
> header that defines it?
I was really only thinking along the lines of keeping it consistent with
how all other headers provide locale_t via __NEED_locale_t.
I don't believe there are any real benefits and that any software package
already doing this should be easily patch-able.
>> string.h:88:
>> gcc generates an implicit-function-declaration warning from alloca
>> when using strdupa. aside: glibc also provides strndupa.
>
> We discussed making this definition depend on __GNUC__ and then it
> could use __builtin_alloca and GCC extensions needed to make strndupa
> work. There might be an old patch floating around to do something like
> that.
OK.
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.
