sprintf(3s) query

Guy Harris guy at auspex.UUCP
Sat Dec 10 03:47:50 AEST 1988


>It seems that in 4.3 BSD (and before?) sprintf doesn't lint right
>except on a VAX.

More correctly, you have to declare "sprintf" yourself, even if you've
included <stdio.h>, except on a VAX.

>What's going on?

Since "sprintf" wasn't declared, when it was first used the compiler
implicitly declared it as returning "int", which disagrees with the
"lint" library.

>And why just the error in line 9.

Beats me.  I tried it on this Sun running 4.0, and it complained about
line 7...

>Why not in line 7 as well?

...and not about line 9.  The 4.0 behavior is argably correct; it
complains about line 7 because that's the first line on which "sprintf"
is used, and therefore is the line on which it's declared.  Since it's
already been declared by line 9, no complaint is issued for that line.

>  (1) What is "too painful to do right" and why?

It was too painful to change "sprintf" to return the number of
characters it generated, rather than returning its first argument; too
many programs relied on that behavior.

The original V7 "sprintf" returned its first argument.  In System III,
or perhaps earlier, all the "*printf" routines were changed to return
the number of characters generated.  4.xBSD was derived from UNIX 32V,
which was derived from V7, so it had the old-style "sprintf".

>  (2) Why doesn't lint give an error for line 7 as well?  I'm not
>      asking for an explanation of why lint does this.  I want a
>      justification of why it *should* do this.

It only gives an error for line 9 because there's a bug, presumably.  It
*should* only give an error for line 7, for the reasons listed above.

The dpANS specifies that they all return the number of characters
generated, and POSIX inherits this from the dpANS (I think); this will
probably prompt Berkeley to say "change your code or die" and adopt the
new-style behavior (the pain involved nonwithstanding).



More information about the Comp.lang.c mailing list