From owner-freebsd-current Tue Jul 3 2:34:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D4FE137B401 for ; Tue, 3 Jul 2001 02:34:35 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA23847; Tue, 3 Jul 2001 19:31:07 +1000 Date: Tue, 3 Jul 2001 19:29:07 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Jeremy Cc: Giorgos Keramidas , current@FreeBSD.ORG Subject: Re: funny strlen defines in sys/alpha/alpha/alpha-gdbstub.c In-Reply-To: <20010703090423.V506@gsmx07.alcatel.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 3 Jul 2001, Peter Jeremy wrote: > On 2001-Jul-02 11:34:25 +0300, Giorgos Keramidas wrote: > > 130 #define strlen gdb_strlen > > 131 #define strcpy gdb_strcpy > > > >Is it really necessary to do this funny thing with the #defines? I > >mean, why not replace the calls with gdb_XXX() ourselves and be done > >with it? Sort of. ${MACHINE_ARCH}-gdbstub.c is sort of contrib'ed code, so we should wait for the vendor to fix this. > Alternatively, given the XXX comment, why not delete the local copies > of str{cpy,len}() and just usr the library versions? The original > reason appears to be to avoid the possibility that str{cpy,len}() are > not re-entrant. The FreeBSD ones _are_ re-entrant and it doesn't seem > likely that we will re-write them not to be re-entrant. The XXX comment applies to the code without the defines. It was removed in the i386 version when these defines were added in rev.1.12. See the comment for some of the other reasons why naming the private versions the same as the extern versions is bad. Yet another reason: strlen() and strcpy() are now normally gcc builtins, so the extern versions are rarely actually used, but you have know too much about how the gcc builtins are implemented to be sure that they are safe to use here. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message