From owner-svn-src-head@FreeBSD.ORG Mon Sep 8 04:20:00 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B8FD99E; Mon, 8 Sep 2014 04:20:00 +0000 (UTC) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id D2B0C17A8; Mon, 8 Sep 2014 04:19:59 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 776913C1DB8; Mon, 8 Sep 2014 14:19:45 +1000 (EST) Date: Mon, 8 Sep 2014 14:19:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rui Paulo Subject: Re: svn commit: r270261 - head/sys/sys In-Reply-To: <0DD8929C-983D-49FD-A904-7A4FF9A3D2CB@me.com> Message-ID: <20140908131951.D880@besplex.bde.org> References: <201408210901.s7L91gZ7049822@svn.freebsd.org> <0DD8929C-983D-49FD-A904-7A4FF9A3D2CB@me.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=BdjhjNd2 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=I7rZfSrdNaYA:10 a=GOI3ijG3_T8A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=UyTiIiJ66uMYDvbjWXgA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: Davide Italiano , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 08 Sep 2014 04:20:00 -0000 On Sun, 7 Sep 2014, Rui Paulo wrote: > On Aug 21, 2014, at 02:01, Davide Italiano wrote: >> >> Author: davide >> Date: Thu Aug 21 09:01:42 2014 >> New Revision: 270261 >> URL: http://svnweb.freebsd.org/changeset/base/270261 >> >> Log: >> Revert r270227. GCC doesn't like the lack of LL suffix, >> so this makes powerpc build failing. >> >> Modified: >> head/sys/sys/time.h >> >> Modified: head/sys/sys/time.h >> ============================================================================== >> --- head/sys/sys/time.h Thu Aug 21 08:25:46 2014 (r270260) >> +++ head/sys/sys/time.h Thu Aug 21 09:01:42 2014 (r270261) >> @@ -129,7 +129,7 @@ bintime_shift(struct bintime *_bt, int _ >> #define SBT_1MS (SBT_1S / 1000) >> #define SBT_1US (SBT_1S / 1000000) >> #define SBT_1NS (SBT_1S / 1000000000) >> -#define SBT_MAX 0x7fffffffffffffff >> +#define SBT_MAX 0x7fffffffffffffffLL > > I also think this is more correct. This is abominably less correct: - it uses the long long abomination - the long long abomination doesn't even give the correct type on any 64-bit arch, except possibly on broken development versions of arm or mips where the long long abomination is used for int64_t. The correct type is sbintime_t = int64_t. This is plain long on all 64-bit arches except possibly the broken ones. - the unsuffixed constant automatically has the correct type (the smallest one that works), except possibly in preprocessor expressions where the rules are quite different - the correct type is already used for all the other SBT constants visible in the diff. Just 1 line outside of the diff there is an example of a correct definition: % #define SBT_1S ((sbintime_t)1 << 32) The cast in this makes it unsuitable for use in preprocessor expressions, but since that is apparently not a problem for any of the old definitions it should be even less of a problem for a new definition. None of this is documented. If it were documented, the documenation should say that none of these macros is suitable for use in a preprocessor expressions. The abomination is being used to work around a compiler warning for broken C90 compilers on 32-bit systems. These compilers support long long and don't warn for it, but they need to support large constants to go with the long longs and they do warn for those unless they have an LL suffix. The idea is to require all uses of long long to be explicit. This may have been better for 32-bit arches in 1990, but it was worse for 64-bit arches even then (except broken ones that made long 32 bits). These arches never needed long long. powerpc is apparently still using the 1990 compiler options that give this warning. That's in the kernel. Compiler options in userland are different and more variable. Since SBT_* are undocumented, any use of them outside the kernel is a bug and we only have to make the kernel use work. Bruce