Re: getpass() feature test macro

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

Hello Rich,

On Thu, 10 Jul 2025 11:54:18 -0400
Rich Felker <dalias@libc.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