[musl] getpass() feature test macro

[musl] getpass() feature test macro

[Thomas Petazzoni]

Hello,

I am working on a build failure happening with the gcr package
(https://gitlab.gnome.org/GNOME/gcr/) due to its use of the getpass()
function in:

  https://gitlab.gnome.org/GNOME/gcr/-/blob/main/gcr/console-interaction.c?ref_type=heads

This fails to build with gcc >= 14 musl toolchains because it doesn't
find the prototype for getpass() even though it's defined in <unistd.h>
which is included.

musl provides the getpass() prototype when:

#if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)

glibc provides the getpass() prototype when:

#if defined __USE_MISC || (defined __USE_XOPEN && !defined __USE_XOPEN2K)

The gcr code base is built with _XOPEN_SOURCE defined, so the build
works fine with glibc, but not with musl.

According to https://man7.org/linux/man-pages/man3/getpass.3.html the
feature test macro requirements for glibc are:

       getpass():
           Since glibc 2.2.2:
               _XOPEN_SOURCE && ! (_POSIX_C_SOURCE >= 200112L)
                   || /* glibc >= 2.19: */ _DEFAULT_SOURCE
                   || /* glibc <= 2.19: */ _BSD_SOURCE
           Before glibc 2.2.2:
               none

So, now the $100 question is: is it gcr that needs to be fixed to
define another feature macro (and if so, which one), or is it musl's
code that should provide getpass() prototype under different conditions?

Thanks a lot in advance for your feedback!

(Obviously the feedback of "getpass is legacy and sucks" isn't very
useful, as it's not the point of this discussion and this fact is known
and understood.)

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

Re: getpass() feature test macro

[Thorsten Glaser]

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.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Re: [musl] getpass() feature test macro

[Rich Felker]

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.

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.

Rich

Re: [musl] getpass() feature test macro

[Thomas Petazzoni]

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?

> 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().

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

Re: getpass() feature test macro

[Rich Felker]

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

Re: getpass() feature test macro

[Thomas Petazzoni]

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

Re: getpass() feature test macro

[Rich Felker]

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

Re: getpass() feature test macro

[Thomas Petazzoni]

On Thu, 10 Jul 2025 12:01:30 -0400
Rich Felker <dalias@libc.org> wrote:

> It's called _DEFAULT_SOURCE because it's what's exposed by default
> (defined by default) if no more restrictive FTMs were already defined.

But they are defining _XOPEN_SOURCE because they use strptime(), which
requires _XOPEN_SOURCE.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com

Re: getpass() feature test macro

[Rich Felker]

On Thu, Jul 10, 2025 at 06:13:53PM +0200, Thomas Petazzoni wrote:
> On Thu, 10 Jul 2025 12:01:30 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > It's called _DEFAULT_SOURCE because it's what's exposed by default
> > (defined by default) if no more restrictive FTMs were already defined.
> 
> But they are defining _XOPEN_SOURCE because they use strptime(), which
> requires _XOPEN_SOURCE.

It only "requires _XOPEN_SOURCE" if you're writing code that defines
_POSIX_SOURCE or (via -std=...) __STRICT_ANSI__ such that you're
starting with a very strict namespace that doesn't expose anything
outside of it.

There are two options here. Either:

1. You stick to strictly following the standards, and not using things
   outside them, and declare that intention with one or more of the
   standards-specified feature test macros, or

2. You write to "whatever your platform has by default or as
   extensions", leaving the standard FTMs undefined or also defining
   the appropriate extension FTMs to get whatever extensions you want.

What this program seems to be doing is requesting a strict standards
environment and then expecting to be able to use something that's not
part of the standard.

So either drop _XOPEN_SOURCE, drop use of getpass, or add explicit
_BSD_SOURCE or _DEFAULT_SOURCE to get some extensions.

Rich

Re: [musl] getpass() feature test macro

[Haelwenn (lanodan) Monnier]

[2025-07-09 19:56:14-0400] Rich Felker:
>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.
>
>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.
>
>Rich

getpass() was in SUSv2 but already marked legacy: https://pubs.opengroup.org/onlinepubs/007908799/xsh/getpass.html

SUSv2 uses _POSIX_C_SOURCE 199506L: https://pubs.opengroup.org/onlinepubs/007908799/xsh/compilation.html

And expectedly, SUSv3 removed it: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap01.html

Which uses _POSIX_C_SOURCE 200112L: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html

Best Regards

Re: [musl] getpass() feature test macro

[Haelwenn (lanodan) Monnier]

[2025-07-11 02:46:11+0200] Haelwenn (lanodan) Monnier:
>[2025-07-09 19:56:14-0400] Rich Felker:
>>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.
>>
>>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.
>>
>>Rich
>
>getpass() was in SUSv2 but already marked legacy: https://pubs.opengroup.org/onlinepubs/007908799/xsh/getpass.html
>
>SUSv2 uses _POSIX_C_SOURCE 199506L: https://pubs.opengroup.org/onlinepubs/007908799/xsh/compilation.html
>
>And expectedly, SUSv3 removed it: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap01.html
>
>Which uses _POSIX_C_SOURCE 200112L: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html

PS: Looking at the PDFs, it has EX shading (extension, seems like early form of XSI shading); so feature macro should be (_XOPEN_SOURCE < 600).
But `_XOPEN_SOURCE && ! (_POSIX_C_SOURCE >= 200112L)` seems okay, just potentially misleading due to the !

Best Regards

Re: [musl] getpass() feature test macro

[A. Wilcox]

On Jul 10, 2025, at 19:58, Haelwenn (lanodan) Monnier <contact@hacktivis.me> wrote:
>> 
>> getpass() was in SUSv2 but already marked legacy: https://pubs.opengroup.org/onlinepubs/007908799/xsh/getpass.html
>> 
>> SUSv2 uses _POSIX_C_SOURCE 199506L: https://pubs.opengroup.org/onlinepubs/007908799/xsh/compilation.html
>> 
>> And expectedly, SUSv3 removed it: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap01.html
>> 
>> Which uses _POSIX_C_SOURCE 200112L: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html
> 
> PS: Looking at the PDFs, it has EX shading (extension, seems like early form of XSI shading); so feature macro should be (_XOPEN_SOURCE < 600).
> But `_XOPEN_SOURCE && ! (_POSIX_C_SOURCE >= 200112L)` seems okay, just potentially misleading due to the !
> 
> Best Regards

Actually, not quite!  That shading is used in SUSv2 for any “feature group” - of which “LEGACY” is one.  A conforming implementation that implements all legacy interfaces is meant to define _XOPEN_LEGACY to something other than -1, and a conforming implementation that does *not* implement legacy interfaces is meant to define _XOPEN_LEGACY to -1.  It does not, afaik, affect which feature macros should be used to request it

They seem to have missed a few “de-shadings”, too, because i.e. getpgid is still shaded as XSI even though it was moved to Base for Issue 5.

As a historical note, SUSv1 (Issue 4, Version 2), which is the oldest standard I still have, shades XSI interfaces as “UX” and the “To Be Withdrawn” (what became LEGACY) interfaces as “EX”; it wasn’t until SUSv2 (Issue 5) when it seems all the shading was unified.  The explanation is found in the change history of <unistd.h> there - these legacy functions were added there but marked as “extensions” because they are “not necessary to implement the base specification”.

Best,
-Anna

Re: getpass() feature test macro

[Thorsten Glaser]

Thomas Petazzoni dixit:

>On Thu, 10 Jul 2025 12:01:30 -0400
>Rich Felker <dalias@libc.org> wrote:
>
>> It's called _DEFAULT_SOURCE because it's what's exposed by default
>> (defined by default) if no more restrictive FTMs were already defined.
>
>But they are defining _XOPEN_SOURCE because they use strptime(), which
>requires _XOPEN_SOURCE.

Perhaps define _ALL_SOURCE, _DEFAULT_SOURCE and the likes instead,
if you need functions from more than exactly one standard.

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc