Date: Wed, 27 Jun 2001 22:55:20 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Pentchev <roam@orbitel.bg> Cc: arch@FreeBSD.ORG, audit@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: patch for '%lld' handling in *scanf(3) Message-ID: <Pine.BSF.4.21.0106272217190.22955-100000@besplex.bde.org> In-Reply-To: <20010627140322.C19162@ringworld.oblivion.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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.). > 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0106272217190.22955-100000>