On Thu Mar 3 06:18:48 UTC 2016 Bruce Evans wrote:
> On Thu, 3 Mar 2016, Justin Hibbits wrote:
>
> > Log:
> > Replace all resource occurrences of '0UL/~0UL' with '0/~0'.
> >
> > Summary:
> > The idea behind this is '~0ul' is well-defined, and casting to uintmax_t,
> > on a
> > 32-bit platform, will leave the upper 32 bits as 0. The maximum range of a
> > resource is 0xFFF.... (all bits of the full type set). By dropping the
> > 'ul'
> > suffix, C type promotion rules apply, and the sign extension of ~0 on 32
> > bit
> > platforms gets it to a type-independent 'unsigned max'.
>
>
> Why not use the correct signed value? This value is -1, not the value, if
> any, with all bits 1. All bits 1 might be a trap representation, but it
> is unclear if ~0 can give a trap representation or a trap since it is
> unclear if the '~' operation acts on padding bits. It is clear that all
> bits 1 gives has value -0 in 1's complement if there are no no padding
> bits. But -0 has the same value as +0. When converted to an unsigned
> type, it loses all traces of its sign, and becomes plain (ufoo_t)0.
>
> I don't like the plan to change the resource range type to uintmax_t.
> 64 bits is just bloat for most 32-bit systems. After fixing all the
> hard-coded u_longs, you can just use a typdefed type which should be
> uint32_t if possible.
>
> Bruce
My original attempt to send svn-src-head a note on this did not seem to go
through.
I tried to interpret C11, C99, and part of C++11 on the point for C11/C99's
allowed value representations, other than the familiar/common 2's complement.
As usual for me this is based on just the language standards. Other standards
may have other rules.
I'm including it below. May be it will make it though this time?
===
Mark Millard
markmi at dsl-only.net
On 2016-Mar-3, at 3:22 AM, Mark Millard <markmi at dsl-only.net> wrote:
[Trying again with a corrected E-mail address.]
What does FreeBSD support of the the possible implementation-defined aspects
for signed-integral value representations for C? C++? I ask because of 1's
complement and signed magnitude as reported on below. . .
[I'm not covering signed conversion to less precision in the below wording.]
[First a note: conversion vs. promotion
Promotions and conversions do not have equivalent rules if I remember right,
which can make the distinction important.
0 is of type int already and does not get promoted before the value is used by
~.
~0 is also of type int and is only later subject to possible conversion, not
promotion.
(As worded this presumes any "negative zero" that might result is not a trap
representation. See below.)
]
As I understand the modern rules from reading the C11 and C99 standards:
One's complement:
If "negative zero" is a trap representation then ~0 is undefined. (Also true
for &, |, ^, <<, and >> use with operands that would otherwise produce such a
trap representation.)
Otherwise ~0 is represented as -0 ("negative zero"). That -0 compares as -0 ==
0 and the like. "Sign extension" (conversion) of signed integral types to
no-less precision (still signed) is value preserving when no trap
representation is involved, so the overall result is then some value
representation of zero: possibly "negative zero" but alternately just zero: "if
the value can be represented by the new type, it is unchanged". (The
mathematical-value is unchanged, not necessarily the representation.)
Later conversion to an unsigned integral type would not convert to a non-zero
value: "if the value can be represented by the new type, it is unchanged".
(That is a mathematical-value preserving statement, not a representation
statement.) So in this context the unsigned result has the zero
value-representation for its precision even if the conversion starts with a
"negative zero".
signed magnitude:
signed magnitude ~0 has value representation all-ones with value -INT_MAX.
"Sign extension" (conversion) of signed integral types to no-less precision
(still signed) is value preserving when no trap representation is involved.
All-ones would not be value preserving for greater precision. Instead zeros
fill the "new" magnitude value-representation bits and the sign bit and the old
"magnitude bits" are preserved.
Later conversion to an unsigned integral value of an unsigned integral type
with, say, IVMAX as its maximum value then (effectively) mathematically adds
the mathematical value (IVMAX+1) to bring the signed value into into the range
of the unsigned integral type. So mathematically: (-INT_MAX)+(IVMAX+1) = IVMAX
- (INT_MAX-1).
Two's complement:
I'll not cover this (common and familiar).
C++11's fit with the above:
There are notes in C++11 about "if the underlying type as padding bits, trap
bits, or alternate representations of the same value" (such as for
compare-and-exchange). So the concepts are involved.
C++11 allows 2's complement, 1's complement, and signed magnitude as examples.
But its wording allows more: "integral types shall define values by use of a
pure binary numeration system" (with a foot note giving more detail).
For conversions: "If the destination type is unsigned, the resulting value is
the least unsigned integer congruent to the source integer" (modulo
2**precision). (I'm using ** for "raised to the power".) Also: "If the
destination type is signed, the value is unchanged if it can be represented in
the destination type (and bit-field width); otherwise the value is
implementation defined."
[Unfortunately there is no definition given of "congruent". It is likely
intended as a modular arithmetic congruence relation: "a congruent_to b (mode
n)" meaning (a-b) is an integral multiple of n. So: least non-negative m such
that (source_integer - m) is a integral multiple of (2**precision). I do not
expect that this would contradict the above C11/C99 material for the 3 value
representations that C11/C99 allow.]
===
Mark Millard
markmi at dsl-only.net
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "[email protected]"
