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 14055 invoked from network); 7 Mar 2022 13:19:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2022 13:19:03 -0000 Received: (qmail 13946 invoked by uid 550); 7 Mar 2022 13:19:00 -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 13911 invoked from network); 7 Mar 2022 13:19:00 -0000 Date: Mon, 7 Mar 2022 08:18:47 -0500 From: Rich Felker To: "wangjianjian (C)" Cc: musl@lists.openwall.com Message-ID: <20220307131847.GJ7074@brightrain.aerifal.cx> References: <6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] basename with no parameter? 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