Re: getpass() feature test macro

[Rich Felker <dalias@libc.org>]

On Thu, Jul 10, 2025 at 09:55:53AM +0200, Thomas Petazzoni wrote:
> Hello Rich,
> 
> Thanks for your super quick feedback, as usual!
> 
> On Wed, 9 Jul 2025 19:56:14 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > On Thu, Jul 10, 2025 at 12:20:42AM +0200, Thorsten Glaser wrote:
> > > On Wed, 9 Jul 2025, Thomas Petazzoni wrote:
> > >   
> > > >               _XOPEN_SOURCE && ! (_POSIX_C_SOURCE >= 200112L)  
> > 
> > This looks like a bug: a search for getpass in POSIX returns
> > no match.  
> 
> A bug in the getpass(3) documentation?

Possibly. The man page documents it just for glibc, which is poor
form. But I doubt even glibc exposes it in later POSIX profiles. Doing
so would be non-conforming (namespace violation).

> > It was probably in an older version of POSIX (possibly XSI shaded, not
> > sure). Generally we don't provide full compat with older versions of
> > the standards, since it turns into a mess of version conditions and
> > programs using a mix of older stuff are usually better off just with
> > _DEFAULT_SOURCE (alias _BSD_SOURCE). There are a few exceptions for
> > stuff that's still widely used like gethostby* that recent standards
> > removed, but I'm not sure it would make sense to treat getpass special
> > like that being that it's a rarely used and IIRC removed a long time
> > ago.
> 
> 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.

Rich