Date: Wed, 12 Sep 2001 06:14:00 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: Mark Murray <mark@grondar.za>, Peter Wemm <peter@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern subr_prf.c src/sys/sys systm.h Message-ID: <20010912060306.Y7389-100000@delplex.bde.org> In-Reply-To: <200109111446.f8BEknK07078@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Sep 2001, Brian F. Feldman wrote:
> Bruce Evans <bde@zeta.org.au> wrote:
> > On Mon, 10 Sep 2001, Brian F. Feldman wrote:
> > > Agreed. Peter's original comment was absolutely justified. The _ONLY_ case
> > > I can see this possibly being even moderately alright is if it is somehow
> > > done in a way that makes it act like a macro definition and can be
> > > #undefined or (called)() in one of the standard ways.
> >
> > Disagreed. This seems like a normal optimization to me. It's like
> > replacing strlen("foo") by 3.
>
> So you don't take issues at all with GCC not only implementing the C
> language per se but implementing actual C library routines, no matter how
> standard they may be, in the compilation step?
Right. The C library is part of the C language (in the hosted case).
I would only disagree with the compiler implementing the library in a
way that significantly constrains the implementation of the parts of
the library that the compiler doesn't implement. E.g., it would be
bad for it to convert printf("%s", "a") into builtin inline
putc('a', stdin) where stdin is only compatible with Linux's stdio.h
:-). OTOH, it already has to constrain the library for very
machine-dependent things like varargs.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010912060306.Y7389-100000>
