Re: getpass() feature test macro

[Rich Felker <dalias@libc.org>]

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@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.

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