Date: Wed, 27 Jun 2001 16:33:10 +0300 From: Peter Pentchev <roam@orbitel.bg> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: patch for '%lld' handling in *scanf(3) Message-ID: <20010627163310.G19162@ringworld.oblivion.bg> In-Reply-To: <Pine.BSF.4.21.0106272217190.22955-100000@besplex.bde.org>; from bde@zeta.org.au on Wed, Jun 27, 2001 at 10:55:20PM %2B1000 References: <20010627140322.C19162@ringworld.oblivion.bg> <Pine.BSF.4.21.0106272217190.22955-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 27, 2001 at 10:55:20PM +1000, Bruce Evans wrote:
> On Wed, 27 Jun 2001, Peter Pentchev wrote:
>
> > Somebody told me in private mail that this change should be accompanied
> > by an update to the scanf(3) manual page. At a quick look at the manual
> > page, the 'q' modifier is documented as providing a 'long long int' value.
>
> This is a bug IMO. 'q' provides a quad_t value (but see below).
>
> > Thus, it seems that 'q' and 'll' should be equivalent, if 'q' is documented
> > as doing exactly what 'll' should do.
>
> 'll' provides a 'long long' value, although it is currently (mis)implemented
> by type punning long iongs to quad_t's.
>
> > What to do now? Use my first patch (with 'll' adding QUAD to the flag),
> > or define the new LONGLONG type? If the latter, should 'q' retain the QUAD
> > type, or use the LONGLONG type? In any case, how should the manpage
> > be worded (WRT both 'll' and 'q')?
>
> Use your second patch. Also, implement it right by not type punning
> long longs as quads or using strtoq() to parse them (use strtoll()).
> Maybe fix the longstanding breakage of overflow handling from misusing
> strtoq() instead of strtol() to parse long values while you are there.
Eep.. ok, I completely forgot about strtoll().
> > FWIW, here's a chart of the current situation in the several BSD's:
> >
> > LONGLONG flag QUAD flag %lld type %qd type
> >
> > FreeBSD no no none quad_t
> > OpenBSD no yes quad quad_t
> > NetBSD yes yes long long quad_t
>
> This oversimplifes things :-). %qd is for quad_t's, but gcc's format
> checker thinks that it is for long longs (at least for printf, and I
> think scanf is no different here. Since quad_t's are plain longs
> on some machines (alphas), %qd is unusable in practice (in code that
> must compile with WARNS=2, etc.).
Yes, I didn't say it was complete, I didn't say any of it was correct,
it was just a look at lib/lib/stdio/{scanf.3,vfscanf.c} in the various
BSD's :)
> > All the manpages document 'q' as producing a 'long long', and none
> > of the manpages mention 'll'.
>
> The FreeBSD printf.3 documents this correctly.
>
> quad_t and %q should go away when C99's intmax_t and %j become Normal.
> I think it is time to deprecate them in man pages. (%q is already
> deprecated in the kernel by not permitting it in FreeBSD's version of
> gcc's format checker for gcc -fformat-extensions.) long long and %ll
> unfortunately won't go away, but using them will usually be wrong.
Hmm maybe I should spend some more time on this, and at least implement
%j? NetBSD has implemented some C99 extensions already..
G'luck,
Peter
--
Thit sentence is not self-referential because "thit" is not a word.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010627163310.G19162>