From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.linux.lib.musl.general/22227 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getpass() feature test macro Date: Thu, 10 Jul 2025 12:01:30 -0400 Message-ID: <20250710160130.GW1827@brightrain.aerifal.cx> References: <20250709235242.6ab2aaeb@windsurf> <20250709235613.GS1827@brightrain.aerifal.cx> <20250710095553.46e836df@windsurf> <20250710155417.GV1827@brightrain.aerifal.cx> <20250710175654.1013755f@windsurf> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7648"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.9.5 (2018-04-13) Cc: Thorsten Glaser , musl@lists.openwall.com To: Thomas Petazzoni Original-X-From: musl-return-22247-gllmg-musl=m.gmane-mx.org@lists.openwall.com Thu Jul 10 18:01:53 2025 Return-path: Envelope-to: gllmg-musl@m.gmane-mx.org Original-Received: from second.openwall.net ([193.110.157.125]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1uZtib-0001uY-03 for gllmg-musl@m.gmane-mx.org; Thu, 10 Jul 2025 18:01:53 +0200 Original-Received: (qmail 23588 invoked by uid 550); 10 Jul 2025 16:01:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: x-ms-reactions: disallow Original-Received: (qmail 22515 invoked from network); 10 Jul 2025 16:01:39 -0000 Content-Disposition: inline In-Reply-To: <20250710175654.1013755f@windsurf> Xref: news.gmane.io gmane.linux.lib.musl.general:22227 Archived-At: 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 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