[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250710175654.1013755f@windsurf>
Date: Thu, 10 Jul 2025 17:56:54 +0200
From: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
To: Rich Felker <dalias@...c.org>
Cc: Thorsten Glaser <tg@...bsd.de>, musl@...ts.openwall.com
Subject: Re: getpass() feature test macro
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.
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
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.
