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=-11.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5787 invoked from network); 7 Mar 2022 16:43:20 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2022 16:43:20 -0000 Received: (qmail 22059 invoked by uid 550); 7 Mar 2022 16:43:18 -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 22023 invoked from network); 7 Mar 2022 16:43:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FTe0unDBO4uNis9+q/oERBjb63KUkdiDmMMVf4E7Mp8=; b=YbctvAb8ZmBAseUX83AAjQisL4l50iE5KYT/a22ZKeatBOmn2lB/5/Jb0Nr/CvHrsF E96w7X+vfBQkr1DA7Dtnws+J4zywmokmAUFwTL7yT5KnhIVpj3MTBfMRvlFQyhsJWe36 bqMcSgbBhPDuZpr1gfy1r6JWrSAhvgkNklP3dRWVBGhcMZqVEKKaFwAd/9+3SKpxgxLs sFAKgN8OrodE55Mzdi16FOE5AjCy/cE9JzLIRpW5yQ/+Imb+WPKA5ki6tAwqLaxa7FWr 70HOkI4cHTz15KZNH3/k5m4C/6PnXLOHcU4qtIIw/12U2AXFFWa4djADhOcP3SVGXR5A SeBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FTe0unDBO4uNis9+q/oERBjb63KUkdiDmMMVf4E7Mp8=; b=7rm9uj+KS6b1L415Ig98gmPYS0Ia1I6JNLR5MawsCcu5q4MYC6OJQb0DlecSBzucJB Td5HeAzpkLYMhojjfjDUCYMzsACZWTPVtEStZExt3ZnKsQIJ89BaVUWXEESXe1rb4Orq EZlXdpAMzsVScqvtWe7YxMQnlIaFexf4G7fgHdBU42MC6vDwkJqMUNnDKLPn/GVmQG8Z vPLTFNoGbuZU1mbt8RkDzzOtfukl1X60xzXArP8jRIgs/gx6Mq+8eFWcSH1dwFeYVVGh MweJvjSmupvEAlJln0grUTcubnfh8uKFqJ5cmgqhdoDghyi2SblcQEEs4st2HnK98EJ2 Rlgg== X-Gm-Message-State: AOAM532ftWDirpJW+rgP077svSb+qdAfVcxUcQbWp2mjikRvVqNRCm3k uchrFO+4T05cASa99aE7D87Fc7xSdAEezhuoSjoIjdoJ8DX6qA== X-Google-Smtp-Source: ABdhPJwGww3ENsNMRHAp8qvfpr+j+mg25ho7Y2uk4Z+lMV5DrfxyM5u1AWHOa4KRs7PxvCK9154VTwohlLjL5DNQj2c= X-Received: by 2002:a2e:a7c2:0:b0:247:ebfe:c423 with SMTP id x2-20020a2ea7c2000000b00247ebfec423mr693252ljp.304.1646671386008; Mon, 07 Mar 2022 08:43:06 -0800 (PST) MIME-Version: 1.0 References: <6f06bbee-2e89-2ebe-ac18-4541d0696204@huawei.com> <20220307131847.GJ7074@brightrain.aerifal.cx> In-Reply-To: <20220307131847.GJ7074@brightrain.aerifal.cx> From: James Y Knight Date: Mon, 7 Mar 2022 11:42:39 -0500 Message-ID: To: musl@lists.openwall.com Cc: "wangjianjian (C)" Content-Type: multipart/alternative; boundary="00000000000006e2e905d9a38f9c" Subject: Re: [musl] basename with no parameter? --00000000000006e2e905d9a38f9c Content-Type: text/plain; charset="UTF-8" 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). 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. 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 > --00000000000006e2e905d9a38f9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that the C2x standard intends to remove deprecated no= n-prototype declarations, along with K&R-style non-prototype definition= s. Empty parens=C2=A0in a declaration will be treated as a zero-arg prototy= pe, just as in C++. (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm).

Additionally, compilers may start emitting some default-o= n warnings for use of these deprecated features even in pre-C2x language mo= des, although that'd=C2=A0likely be suppressed for system headers.
<= div>


On Mon, Mar 7, 2022 at 8:19 AM Rich Felker &l= t;dalias@libc.org> wrote:
On Mon, Mar 07, 2022 at= 10:31:41AM +0800, wangjianjian (C) wrote:
> Hi all,
>
> I find that the basename in string.h=C2=A0 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<= br> musl and it's the standard one.

The reason for the non-prototype declaration is explained in commit
37bb3cce4598c19288628e675eaf1cda6e96958f:

=C2=A0 =C2=A0 omit declaration of basename wrongly interpreted as prototype= in C++

=C2=A0 =C2=A0 the non-prototype declaration of basename in string.h is an u= gly
=C2=A0 =C2=A0 compromise to avoid breaking 2 types of broken software:

=C2=A0 =C2=A0 1. programs which assume basename is declared in string.h and= thus
=C2=A0 =C2=A0 would suffer from dangerous pointer-truncation if an implicit=
=C2=A0 =C2=A0 declaration were used.

=C2=A0 =C2=A0 2. programs which include string.h with _GNU_SOURCE defined b= ut then
=C2=A0 =C2=A0 declare their own prototype for basename using the incorrect = GNU
=C2=A0 =C2=A0 signature for the function (which would clash with a correct<= br> =C2=A0 =C2=A0 prototype).

=C2=A0 =C2=A0 however, since C++ does not have non-prototype declarations a= nd
=C2=A0 =C2=A0 interprets them as prototypes for a function with no argument= s, we
=C2=A0 =C2=A0 must omit it when compiling C++ code. thankfully, all known b= roken
=C2=A0 =C2=A0 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
--00000000000006e2e905d9a38f9c--