From owner-svn-src-head@FreeBSD.ORG Tue Jan 3 18:20:21 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7502C106566B; Tue, 3 Jan 2012 18:20:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 0F7DD8FC12; Tue, 3 Jan 2012 18:20:21 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 329672A28DF2; Tue, 3 Jan 2012 19:20:20 +0100 (CET) Date: Tue, 3 Jan 2012 19:20:20 +0100 From: Ed Schouten To: Bruce Evans Message-ID: <20120103182020.GH1895@hoeg.nl> References: <201201030714.q037E2qq010125@svn.freebsd.org> <20120104013401.S6960@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXqTiZo38oDXuAlq" Content-Disposition: inline In-Reply-To: <20120104013401.S6960@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r229368 - in head: lib/libc lib/libc/arm/string lib/libc/i386/string lib/libc/mips/string lib/libc/string lib/libstand sys/boot/userboot/libstand X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:20:21 -0000 --OXqTiZo38oDXuAlq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bruce, * Bruce Evans , 20120103 16:49: > This breaks the Standard C namespace. When they are in the same object > file, there is no way to get the standard name without getting the > nonstandard name. So the following C-standard-conforming C program > now gets a linkage error (multiple definition of `index'), at least with > static linkage: >=20 > #include > int index; > void foo(const char *p) { return strchr(p, '1'); } Though I sympathize, this problem is not just limited to strchr(). There are other portions of the C library that use index() as well. For example, if you use , ttyslot(), one of the exec*() functions or the NIS functions, you already get index() linked into your binary. > [...] and the C > standard might require memcpy and memmove to have different addresses. I just skimmed through the standard, and if I haven't overlooked anything, no such requirement is made. Also, I can imagine a compiler with good support for link-time optimisation can already merge equal pieces of code together, making it even harder to reason about inequality of function addresses. Still, I am willing to address the issues you raised. index() and rindex() aren't that important nowadays and I have a patchset ready in my home directory that converts almost all apps in the base system to use strchr() anyway. As I don't feel like polluting the MI strchr() implementations with index()/rindex() support, would it be okay if I implement index() and rindex() as simple C functions that call into strchr() and strrchr()? --=20 Ed Schouten WWW: http://80386.nl/ --OXqTiZo38oDXuAlq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPA0bjAAoJEG5e2P40kaK7Dp8P/jK/y1yO5Yw4ztVPkhTx2S/K 5+reKjaGBEa6/wvSB3ytoEME6pMIrc4sgs/aKSYVufRaV6MDcVQ2e4llH1oWR9Zg JPNW2S6WYeC0JV0Y3gpXzoIuPaH2W8wYBEVWyhRj0W1+CbUL34NtfJWATsNQxkST Y+vFGCI7Ry3KtllVgJ/IC0N3c9m2EsOh+O0/yLwAS4f/GXjKpQEJsgOuR1EBWUQU tHiRTIzZp6S1upiPTWG5hY0UlvNJfe1jPJ09g8uGrS22a61gLiweTp8nO/VszrLS lIv/4YGt2ycX4UWeEGmfuKng+7qp1NhO2VyWupgLJtCreVbn6I5Y/zhELdfhJPuU hK2MGP2BlkNAK/yylY2IZZa8T7Hnt7SYolb0CT72D1xvJb1FR900Hwq0EKp4YySF 4PdpV5jdK8qINUzVA+zooNwvnvmvdsI0rL1wV5tX0ikkzjTTqjEYLA5aqMn9y4U5 UT3+Dmd12j6c8Uu/NMrnyrbdlqqcRx1ftfONO9meNeYeckuGIZ6klrTHJxgkcb6c oE2Cr++xV1KQLjmbp+biB5xT6mX0J/Sn8TyfYwn34G3E1RVm7ZDh17bJSrjqVXYn TwFBy7199cl9IeSlROCDe6vjKozVUvhCP+zzN4HHFwHscNswUki+xpda7rXX9i5D Qec9D+T7+9EYxezDWCAM =qvDX -----END PGP SIGNATURE----- --OXqTiZo38oDXuAlq--