gets(3) nonsense

[Chris Torek]

In article <6544 at csli.STANFORD.EDU> gandalf at csli.STANFORD.EDU
(Juergen Wagner) writes:
>printf, fprintf, et al. all use an internal buffer of finite size. May I
>quote from the manual:
>
>	BUGS
>	     Very wide fields (>128 characters) fail.

You quote from *a* manual, not *the* manual: this bug is gone in 4.3tahoe.
printf format widths may be arbitrarily large (to MAXINT).  Ridiculous
field widths are handled correctly: e.g., %30000.15000f produces a 30000
character field with 15000 digits of precision, of which the last >14500
will definitely all be zero.  (They are faked.  Getting this right is
difficult; we went through a number of iterations, with Keith Bostic
doing the hard part of floating point formatting and me supplying
perverse test cases.  We finally settled on faking ridiculous precisions,
to avoid blowing away stacks.  Hmm :-) ....)  The manual entry might
still have that BUGS section; I forget whether we got it updated.  A
proper BUGS section is appended below.

Anyway, more or less back to the subject (now that I have finished my
mixed veggies and started the spaghetti water boiling [still hungry]):
the BUGS quote above really means that wider fields are truncated, or
at least that is what the 4.xBSD (x < 3tahoe) vax _doprnt.s tried to do.

[from my printf.3s]
BUGS
     The conversion formats %D, %O, and %U are not standard and
     are provided only for backward compatibility.  The effect of
     padding the %p format with zeros (either by the `0' flag or
     by specifying a precision), and the benign effect (i.e.,
     none) of the `#' flag on %n and %p conversions, as well as
     other nonsensical combinations such as %Ld, are not stan-
     dard; such combinations should be avoided.

Printed 9/13/88           June 5, 1986                          5

-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris