From owner-freebsd-audit Wed Jun 27 6:28:46 2001 Delivered-To: freebsd-audit@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 2829B37B401 for ; Wed, 27 Jun 2001 06:28:34 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 61796 invoked by uid 1000); 27 Jun 2001 13:33:10 -0000 Date: Wed, 27 Jun 2001 16:33:10 +0300 From: Peter Pentchev To: Bruce Evans 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> Mail-Followup-To: Bruce Evans , arch@FreeBSD.ORG, audit@FreeBSD.ORG, freebsd-standards@bostonradio.org References: <20010627140322.C19162@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Wed, Jun 27, 2001 at 10:55:20PM +1000 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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