sprintf(3s) query

[Charlie Geyer]

It seems that in 4.3 BSD (and before?) sprintf doesn't lint right
except on a VAX.  Consider the following little program.

  #include <stdio.h>

  main()
  {
  char s[20];

  sprintf(s,"foo");
  fprintf(stdout," %s\n",s);
  sprintf(s,"foo");
  fprintf(stdout," %s\n",s);
  }

which compiles and works fine.  It also lints fine on a VAX running
4.3 BSD from mt Xinu.  On a Sun-3 running Sun UNIX 4.2 Release 3.2
lint gives the following rather odd error message

  sprintf value declared inconsistently   llib-lc(512)  ::  goo.c(9)

What's going on?  And why just the error in line 9.  Why not in line 7
as well?  Looking /usr/lib/lint/llib-lc we see that lint thinks that
sprintf returns a char * which agrees with what the man page says.
But /usr/include/stdio.h has the following interesting item

  #ifdef vax
  char    *sprintf();             /* too painful to do right */
  #endif

so it doesn't define what sprintf returns (and by default C assumes
that sprintf returns an int).

So two questions:

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

  (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.

This error is not Sun-specific.  On an IBM RT running IBM Academic
Information Systems 4.3 (which somebody told me is approximately 4.3
BSD and looks like it).  /usr/include/stdio.h has the same ifdef and
comment about "too painful to do right" and so does not define what
sprintf returns.  But here the man page doesn't specify the type
sprintf returns either (so int is default).  But /usr/lib/lint/llib-lc
says that sprintf returns a char *.  So the RT gives the same error
message

  sprintf value declared inconsistently   llib-lc(438)  ::  goo.c(9)

The RT has source and /usr/src/lib/libc/stdio/sprintf.c says that
sprintf does indeed return a char *, it's first argument.  So (if the
source is to be believed) the man page and stdio.h are broken.