From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18987 invoked from network); 7 Mar 2022 18:38:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2022 18:38:49 -0000 Received: (qmail 28056 invoked by uid 550); 7 Mar 2022 18:38:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28015 invoked from network); 7 Mar 2022 18:38:45 -0000 Date: Mon, 7 Mar 2022 13:38:32 -0500 From: Rich Felker To: James Y Knight Cc: musl@lists.openwall.com, "wangjianjian (C)" Message-ID: <20220307183831.GL7074@brightrain.aerifal.cx> References: <6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com> <20220307131847.GJ7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] basename with no parameter? On Mon, Mar 07, 2022 at 11:42:39AM -0500, James Y Knight wrote: > Note that the C2x standard intends to remove deprecated non-prototype > declarations, along with K&R-style non-prototype definitions. Empty > parens in a declaration will be treated as a zero-arg prototype, just as in > C++. (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm). I was vaguely aware of this, and it's somewhat unfortunate because it removes some power from the language. There are some magical tricks you can do with non-prototype declarations and _Generic that will no longer be possible... > Additionally, compilers may start emitting some default-on warnings for use > of these deprecated features even in pre-C2x language modes, although > that'd likely be suppressed for system headers. > > It'd probably be a good idea to remove any such hacks which depend on > non-prototype declarations, to get ahead of these changes. Seems like a good idea. I wonder whether we should remove the declaration entirely here or put back the prototype... Rich > On Mon, Mar 7, 2022 at 8:19 AM Rich Felker wrote: > > > On Mon, Mar 07, 2022 at 10:31:41AM +0800, wangjianjian (C) wrote: > > > Hi all, > > > > > > I find that the basename in string.h with _GNU_SOURCE in Musl > > > libc(Line 119): > > > > > > char *basename(); > > > > This is not a declaration with no parameter. It's a declaration > > without any prototype. > > > > > The man page says that have two different version of basename > > > however both need one parameter, is this correct? > > > > No, that's documenting glibc. There is only one version of basename in > > musl and it's the standard one. > > > > The reason for the non-prototype declaration is explained in commit > > 37bb3cce4598c19288628e675eaf1cda6e96958f: > > > > omit declaration of basename wrongly interpreted as prototype in C++ > > > > the non-prototype declaration of basename in string.h is an ugly > > compromise to avoid breaking 2 types of broken software: > > > > 1. programs which assume basename is declared in string.h and thus > > would suffer from dangerous pointer-truncation if an implicit > > declaration were used. > > > > 2. programs which include string.h with _GNU_SOURCE defined but then > > declare their own prototype for basename using the incorrect GNU > > signature for the function (which would clash with a correct > > prototype). > > > > however, since C++ does not have non-prototype declarations and > > interprets them as prototypes for a function with no arguments, we > > must omit it when compiling C++ code. thankfully, all known broken > > apps that suffer from the above issues are written in C, not C++. > > > > This was from 2012, so it might make sense to do something different > > now, like putting the correct prototype there and getting any programs > > it still clashes with fixed. > > > > Rich > >