![]() |
|
Message-ID: <20250710160130.GW1827@brightrain.aerifal.cx> Date: Thu, 10 Jul 2025 12:01:30 -0400 From: Rich Felker <dalias@...c.org> To: Thomas Petazzoni <thomas.petazzoni@...tlin.com> Cc: Thorsten Glaser <tg@...bsd.de>, musl@...ts.openwall.com Subject: Re: getpass() feature test macro On Thu, Jul 10, 2025 at 05:56:54PM +0200, Thomas Petazzoni wrote: > Hello Rich, > > On Thu, 10 Jul 2025 11:54:18 -0400 > Rich Felker <dalias@...c.org> wrote: > > > > Hm, thanks but it still isn't clear to me. If the issue is in the gcr > > > code base, which needs to define another feature macro, I'd like to > > > have some compelling evidence that the code is incorrect and needs to > > > define some other feature macro to use getpass(). > > > > It's not so much "needs to define another feature macro" as "don't use > > feature test macros to request strict POSIX if that's not what you > > want". > > > > It's vaguely possible that this code was written to conform to SUSv2 > > (_XOPEN_SOURCE=500 or _POSIX_C_SOURCE=199506L), in which case that's > > valid but just not a standard we support because it's so outdated. But > > more likely, it's just written to the haphazard "use whatever random > > stuff" principle, in which the right thing to do is not define any of > > these FTMs. > > Thanks, but I'm still confused. As it is today, gcr only defines > _XOPEN_SOURCE and due to that, cannot access getpass() prototype when > building against musl, causing a build failure. What is the solution > that you suggest? *Not* defining any FTM will certainly not fix this, > as musl only exposes the getpass() prototype if either _DEFAULT_SOURCE > or _BSD_SOURCE is defined. It's called _DEFAULT_SOURCE because it's what's exposed by default (defined by default) if no more restrictive FTMs were already defined. 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.