NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/c/18810

Internet Message Format | 1992-12-22 | 3.9 KB

Path: sparky!uunet!munnari.oz.au!goanna!ok
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: definition of strncpy stupid?
Message-ID: <[e-mail]>
Date: 23 Dec 92 04:21:39 GMT
References: <[e-mail]> <[e-mail]>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 68

I realise this thread has been running for a while, but I think I have
something new to say


In article <[e-mail]>, [e-mail] writes:
> In article <[e-mail]> [e-mail] (Dave Turner) writes:
> >>
> >>I agree with the original poster in that there's a need for a function like
> >>strncpy() but that null-terminates the target string. I find it a pain in
> >
> >The function already exists. It is called sprintf. Try:
> >
> >    sprintf(s1, "%.*s", n, s2);
>
> sprintf() is slow. Part of the issue is execution speed.

I also proposed sprintf(), and got E-mail attacking my suggestion somewhat
less than politely.  The blanket claim "sprintf() is slow" simply won't
do.  Once upon a time the str*() functions were just plain old functions
that were in the library because they were handy.  I still have my
UNIX V7+ PDP-11 assembly code files in which I provided my own implementations
of strcpy() and strlen().  (I needed to save a few dozen more bytes so that
my program would fit, and I also needed the increase of speed I got by NOT
using the library functions.)  Nobody has *EVER* promised that strncpy()
would be fast.

On the other hand, X3J11 made explicit a few restrictions that already
applied if you wanted to write portable code, which have the consequence
that a C compiler is fully entitled to "know" about sprintf (and all the
other library functions).  If you use 'sprintf' as an identifier with
external linkage in one of your files, an ANSI C compiler is allowed to
"know" about it in great detail.  (It may, for example, analyse the format
string and give you a compile time warning if there is any mismatch between
that string and the remaining arguments.)  In particular, for any of
fprintf/printf/sprintf, if the format argument is a string literal, the
compiler is entitled to analyse it and replace that call by something fast
that has the same effect.  In particular, a C compiler is fully within its
rights to replace
    sprintf(s1, "%.*s", n, s2)
by
    __substr(s1, n, s2)
where __substr is an implementation-specific substring function.

Your C compiler doesn't do this?  Well, tell the vendor that you wish it
did.  Complain bitterly if it doesn't at least parse the string so that it
can warn about argument msimatches (there are compilers that do it...).
Get sprintf() included in a popular benchmark.

I've seen a "student" Fortran compiler on a slow machine outperform a
"professional" optimizing Fortran compiler on a faster machine simply
because the "student" compiler compiled FORMAT statements (and it gave
better run-tiume diagnostics too, good one Dr Fenwick).  The same could
be done for C, and it WOULD be done if enough people demanded it with
their wallets in their hands.

Now, support sprintf() _is_ slow.  How will it be slow?  Well, it has to
parse the format string (if the compiler hasn't done it already).  That's
a start-up cost which is independent of n.  Then it has to move the
bytes, maintaining a counter as well.  That's maybe 2 to 5 times slower
than a special purpose substring function.  For small strings, BIG DEAL.
For large strings, well, any program which is doing so much text manipulation
that the difference between sprintf() and substr() _matters_ and isn't using
some smarter representation (e.g. there are representations in which
substr() is an O(1) operation) is so horribly badly written that it doesn't
matter.  Even if there were a substr() function in the library, there are
no tasks for which it would be dramatically better than sprinf() for which
they wouldn't both of them be wrong.