Date: Sun, 31 Oct 1999 23:05:45 -0700 From: Warner Losh <imp@village.org> To: Randell Jesup <rjesup@wgate.com> Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <199911010605.XAA04972@harmony.village.org> In-Reply-To: Your message of "01 Nov 1999 01:24:10 GMT." <ybuu2n7gg1x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> References: <ybuu2n7gg1x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <199910312349.CAA02684@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <ybuu2n7gg1x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> Randell Jesup writes:
: Sure, but why not code for efficiency to start with? Especially in
: such an obvious case. I'll bet 95% of programmers working on systems where
: stpcpy has been part of the libraries for a long time don't even know that
: it isn't standard. I don't know about you, but I code for systems where
: cutting CPU usage by 1% can actually make a real difference in the field
: and to costs. Perhaps this won't get me 1% - but a fraction of a percent
: here and another there adds up, and this is at truely zero cost. Other
: people will have applications where this might by more.
Premature sub-micro optimization. There is such a small benefit from
this hack that it would rarely make the program run measurably
faster. It is a small win, but does cause other problems with breaks
standards conformimg programs.
For example, the following program is strictly standards conforming,
but would break if we added this change:
#include <strings.h>
static char foo[1024];
int stpcpy(char *str)
{
if (strlen(str) + strlen(foo) + 1 < sizeof(foo)) {
strcat(foo, str);
return 1;
} else {
return 0;
}
}
int main()
{
printf("stpcpy is %d", stpcpy("foo"));
}
because string.h on linux defines stpcpy to have a different
prototype....
: While non-ANSI standard, this particular function has been
: virtually standard in PC compilers for a Long Time. Like I said, near the
: start of this, probably for more than a decade it's been in every
: DOS/Win/Amiga/OS2/etc compiler I've used (unless my memory fails me, which
: it might).
So all the DOS compilers have it. Who cares. It isn't standards
conforming and encourages people to not know the difference between
standard functions and non standard ones. It makes your code harder
to read, not easier. DOS isn't the standard, and encourages some very
sloppy practices. It makes it harder to port programs written to
these oddball, strange, non-standard interfaces.
Just because it is in every compiler you have ever used doesn't make
it desirable to have it our libc. It has existed in none of the
machines that I have used over the past 10 years, although it did
exist for the c compiler for my DEC Rainbow 100B. I'm sure a survey
of compiler (or rather systems, since unix dices the OS up differently
than the Loader known as DOS) would should that the vast majority of
them do no, in fact, have this function.
: Why is there such vitriol being pointed at people who use a
: function that's been in every compiler they've ever had access to, can't
: hurt performance, could improve performance of heavily string-oriented
: apps, and is small? Quite honestly, I'd assumed that stpcpy() was in
: the library already.
It is that very fact that is why we're against putting it into our
library.
: If I want strict ANSI, I'll tell the compiler that. I can't
: remember the last time I did that - I think it was when I was beta-testing
: commercial compilers 6 or 7 years ago.
Part of the problem is that it pollutes the name space. FreeBSD is
very careful to not overly pollute things.
: As for the bloat argument: Bloat in libraries is very different than bloat
: in executables; the impact is MUCH smaller. And as 'bloat' goes, this is
: about the most trivial example one could come up with. IMHO.
Yes, but if we had 100s of these stupid little things in libc, then it
would get too large. It is the camel nose argument: If the nose of a
camel comes under the tent, the rest of the camel is sure to follow.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911010605.XAA04972>