From owner-svn-src-head@FreeBSD.ORG Wed May 23 09:03:12 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 021DA1065672; Wed, 23 May 2012 09:03:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 86F048FC08; Wed, 23 May 2012 09:03:11 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4N8vYSf004054; Wed, 23 May 2012 18:57:34 +1000 Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4N8vPc1017913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2012 18:57:26 +1000 Date: Wed, 23 May 2012 18:57:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: gnn@freebsd.org In-Reply-To: <861umcx7oe.wl%gnn@neville-neil.com> Message-ID: <20120523173439.I902@besplex.bde.org> References: <201205221818.q4MII7lk019626@svn.freebsd.org> <20120523050739.H3621@besplex.bde.org> <861umcx7oe.wl%gnn@neville-neil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, "David E. O'Brien" , Bruce Evans Subject: Re: svn commit: r235797 - head/contrib/gcc X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 09:03:12 -0000 On Tue, 22 May 2012 gnn@freebsd.org wrote: > At Wed, 23 May 2012 06:05:06 +1000 (EST), > Bruce Evans wrote: >> [... excessive quoting deleted] > >> Now I prefer the old way, after fixing the bugs found by switching. >> It finds more bugs under FreeBSD, and is bug for bug compatible with >> distribution gcc and probably with other system's headers under >> !FreeBSD. Except under FreeBSD, I prefer %q to be an error. The above >> shows it only being used 12 times in /sys, with most uses of it being >> bugs. Fixing these bugs would leave about 1 correct use of it -- for >> printing the quad_t in unreachable code in msdosfs. This use would be >> easy to avoid too (just cast to uintmax_t). Uses in userland are >> hopefully east to fix and avoid too. In an old userland, there were >> only about 50, with most in netstat/inet6.c, tcopy.c, ftpd, fsirand, >> and contrib'ed code. Of course you can't make it an error for the >> contrib'ed code. > > Instead of replying to the original commit I'll just add to the chain. Please don't quote the whole thing, especially when not replying to any of it. > Note that this change broke buildworld: > > src/usr.sbin/ppp/throughput.c: In function 'throughput_disp': > src/usr.sbin/ppp/throughput.c:119: warning: format '%6qu' expects type 'long unsigned int', but argu > > And several more. Of course ppp has several style bugs and type mismatches, else its brokenness wouldn't have been exposed: - the variables have the bogus type "unsigned long long" - they are printed with the mismatched format "%6qu", although there is a perfectly bogus format "%6llu" that matches them exactly. Another point is that libc printf doesn't really support %q. It just maps %q to %ll and accesses the arg using va_arg(ap, long long). Thus it is technically correct in userland for the format checker to also map %q to %ll and disallow printing int64_t with each in the LP64 case. This is also bug for bug compatible with the gcc distribution and perhaps with other OS's. However the kernel printf is more careful. It doesn't map %q to %ll, and it accesses %q args using va_arg(ap, quad_t). Thus it is technically correct in the kernel for the format checker to also _not_ map %q to %ll and _allow_ printing int64_t with %q. However, %q should never be used. The history of the kernel printf shows that I objected to adding %q support to it in 1999, but not strongly enough to keep it out. I should have objected more to adding support for %ll. This was slightly before C99 came out. %j support was needed before then but was not added until 2002. I had prepared for killing long long and quad_t in the kernel by removing many uses of them. When the %q mistake was committed, there were just 90 instances of 'long long' in /sys. 61 of these were in the i386 FPU emulator. 20 were in other code that I didn't care about and/or was soon to go away: alpha: 6 (half wrong and/or easy to avoid) coda: 3 (all wrong and/or easy to avoid) svr4: 4 (all wrong and/or easy to avoid) vinum: 4 (all easy to avoid?) powerpc: 3 (cloned from wrong ones for alpha) The remaining 9 were: 3 that I was responsible for in i386 clock code and a copy for pc98 (to avoid overflow in multiplication) 2 that I was responsible for in i386 basic typedefs (only used for non-gcc) 1 that I was responsible for in sys/param.h (to avoid overflow in shift) 3 in ntp code (all wrong and easy to avoid. The code wanted precisely 64 bits and assumed that long long gave that. The type that gives 64 bits, int64_t, has been standard in FreeBSD since FreeBSD-2. It came from 4.4BSD-Lite1. While counting the above, I noticed that in the middle of 1999 just before the %q changes, there were about 700 references to int64_t (now counting ones in comments). Just 1 year earlier, there were only about 300. The count of long longs didn't change much in that time. For quad_t, the raw counts were 419 in the middle of 1998 and 441 in the middle of 1999. About half were in nfs (183) and libkern (64). Now /sys has and oldnfs has 58. For long long, the raw count is 1577. So, 13 years after C99 stdint.h made long long unnecessary and after mostly avoiding long long when it was only a gcc misfeature, the use of long long has exploded by a factor of about 1577/91 = 17 :-(. The use of int64_t has also exploded: its raw count is 66730 (!); it has exploded by a factor of about 66730/700 = 95. int32_t is only used 46715 times. I fear than many of the uses of fixed width types are wrong too. The fixed widths become part of both APIs and ABIs so they will be hard to change to support 128-bit things. off_t is only used 2223 times. It has the opposite problem that its API is perfect and supports it having any width, but you can't actually change its width easily since bugware will have assumptions that it is precisely 64 bits, just like old bugware assumed that it and long are precisely 32 bits, but multiplied by a bloat factor of 95 or so. intmax_t is only used 1090 times. It has the same expansion problems for ABIs that long used to have. Bruce