4.2 sprintf too painful?

Guy Harris guy at rlgvax.UUCP
Thu Feb 7 13:37:21 AEST 1985


> I've gotten several answers to my question about this cryptic remark in
> the Vax 4.2 /usr/include/stdio.h. ...
> 
> char	*sprintf();		/* too painful to do right */
> 
> Bill Joy put that in at Sun.  "Too painful" means too painful to hunt down
> and fix all the unsupported programs at Berkeley that depend on Berkeley's
> non-standard sprintf return value.  At Sun sprintf was recently changed to
> be compatible with System V.  The lesson to be learned is, don't depend on
> the return value of sprintf.

Another pointer along those lines:

Don't use %D, %O, %X, and the like.  Use %ld, %lo, %lx instead.
The System V (and System III) "printf" family uses %X to mean "hexadecimal
with capital A-F as digits" and doesn't support the others at all.  %ld, etc.
are supported on all "printf"s since V7.

And another tip; this one won't burn you on current systems, but CCI's
4.2BSD/System V Release 2 hybrid system (coming out this year on our Power 6
supermini and on some other systems) won't be happy if you do

	signal(SIGCHLD, SIG_IGN);

In vanilla 4.2BSD, this is equivalent to

	signal(SIGCHLD, SIG_DFL);

(well, 10 or so cycles more are spent in "psignal" dismissing the signal if
you do SIG_DFL instead of SIG_IGN, but then 99% of all processes SIG_DFL
it so who cares).  I decided that SIGCHLD (4.2BSD) and SIGCLD (System V)
were so close in functionality that they were combined into one signal.
The difference is that the S5 SIGCLD, when ignored, tells the system that
you are abandoning your current and future children.  If a child dies, no
zombie is left around.  As such, some programs ("rshd", if I remember correctly)
get confused when they do a SIG_IGN.

Hopefully, a list of all these sorts of warnings - including a "how to" on
dealing with the various TTY drivers - will end up in a document which 1) will
go out with our systems, 2) end up on USENET, and 3) maybe get published.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy



More information about the Comp.unix.wizards mailing list