Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Aug 2014 10:41:23 -0400
From:      Benjamin Kaduk <bjkfbsd@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>
Subject:   Re: svn commit: r270227 - head/sys/sys
Message-ID:  <CAJ5_RoC85T6JA1sz0VT94msM8hoj81QaXKgOfCX_yFNrqz5OdQ@mail.gmail.com>
In-Reply-To: <20140826233018.H32188@besplex.bde.org>
References:  <201408201632.s7KGW2vF093636@svn.freebsd.org> <CAJOYFBDx7EjBD9L8zrMHperzy9qa%2BboZn49LY9TRm7nPE9CRCw@mail.gmail.com> <20140826233018.H32188@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 26, 2014 at 9:58 AM, Bruce Evans <brde@optusnet.com.au> wrote:

>
> That would be a further obfuscation.  The *INT<n>C() macros expand to
> integer constant expressions of the specified type suitable for use
> in #if preprocessing directives.  (It is otherwise difficult to
> detemine the correct suffix, to add to the constant to give it the
> specified type).  There are no preprocessing directives here, so a
> simple cast works.  The cast could also be applied to the other
> operand but it is easier to read when applied to the constant.
>

I thought that in C99, all integers in preprocessor evaluation were treated
as if
they were [u]intmax_t (6.10.1.4 in the n1256.pdf I have here).  I was only
just
skimming that part yesterday for unrelated reasons, though, so maybe I'm
missing the bigger picture.


> The expression could also be written without a cast and without using
> UINT64_C(), by using a 'ULL' suffix instead of 'LL'.  That would still
> use the long long abomination, and be different obfuscation -- the
> type of the constant doesn't really matter, but we need to promote
> to the type of 'frac', that is, uint64_t.  'ULL' works because long
> longs are at least 64 bits (and I think unsigned long longs are also
> 2's complemention, so their type is larger than uint64_t.


Two's complement semantics are guaranteed for the fixed width types
such as int64_t, but I'm not sure how that comes into play for unsigned
types?

-Ben



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoC85T6JA1sz0VT94msM8hoj81QaXKgOfCX_yFNrqz5OdQ>