unsigned int and -1
Brian Nichols
the C standard?
unsigned int x = -1;
I'm asking because I've seen some code that uses such an assignment to
set all of the bits of an unsigned value.
Ben Pfaff
> Does the following line of code have any special meaning according to
> the C standard?
>
> unsigned int x = -1;
It will set all of the value bits of `x', so that `x' will equal
`UINT_MAX'. It is interpreted as a conversion from `int' to
`unsigned int', which is performed by adding `UINT_MAX + 1' to
bring it within the range of `unsigned int', so that the result
is value of `-1 + UINT_MAX + 1' interpreted as a mathematical
(not C) expression, which equals `UINT_MAX'.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming
Martin F.
> Does the following line of code have any special meaning according to
> the C standard?
>
> unsigned int x = -1;
If an integer value is converted to an unsigned integer type (except
_Bool), and the value is outside the range of representable values,
the value which is one greater than the maximum value of the unsigned
type is repeatedly added or subtracted, until the result is in the
range of representable values.
From a two's complement point of view, this just means that the higher
bits of the value are discarded.
If you convert -1 to an unsigned integer type, the result is the
maximum value of that type (and has all value bits set).
> I'm asking because I've seen some code that uses such an assignment to
> set all of the bits of an unsigned value.
This is perfectly correct and portable.
Seppo Citymarket
use ~0 in place of -1 to avoid any problems, does the same thing in same
amount of typing.
Tobias Oed
On my keyboard the ~ requires the shift key to be held down, the - doesn't.
I hate my terminal. On the other hand it's better than ??-.
Tobias.
--
unix http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.programmer.html
clc http://www.eskimo.com/~scs/C-faq/top.html
fclc (french): http://www.isty-info.uvsq.fr/~rumeau/fclc/
Joona I Palaste
> Seppo Citymarket wrote:
>>> unsigned int x = -1;
>>
>> use ~0 in place of -1 to avoid any problems, does the same thing in same
>> amount of typing.
> On my keyboard the ~ requires the shift key to be held down, the - doesn't.
> I hate my terminal. On the other hand it's better than ??-.
> Tobias.
The C language does not define a keyboard layout. On a French keyboard
you have to press the shift key to type numbers. Perhaps then it would
have to be something like:
unsigned int x;
x = -(x==x);
Or does this invoke un{specifi,defin}ed behaviour?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text
d.hope
news:af7s9k$2k5$1...@oravannahka.helsinki.fi...
> Tobias Oed <tob...@physics.odu.edu> scribbled the following:
> > Seppo Citymarket wrote:
> >>> unsigned int x = -1;
> >>
> >> use ~0 in place of -1 to avoid any problems, does the same thing in
same
> >> amount of typing.
>
> > On my keyboard the ~ requires the shift key to be held down, the -
doesn't.
> > I hate my terminal. On the other hand it's better than ??-.
> > Tobias.
>
> The C language does not define a keyboard layout. On a French keyboard
> you have to press the shift key to type numbers. Perhaps then it would
> have to be something like:
> unsigned int x;
> x = -(x==x);
> Or does this invoke un{specifi,defin}ed behaviour?
No, the behavior is well-defined. It has the same behavior as unsigned int
x; x = -1;
d.hope
news:cpKR8.37429$38.51...@zwoll1.home.nl...
Oops, misread it as unsigned char x; x = -(x==x); Of couse the behavior is
undefined when x is of type unsigned int.
Ryan Hennessy
What problems were you hoping to avoid, exactly? Conversion from signed to
unsigned is well-defined by the language specification.
Ryan.
Eric Sosman
Use ~0 in place of -1 to *create* problems; the two are not
necessarily equivalent.
Here's why. The C Standard requires that the implementation
use one of three specified encodings for negative integers: two's
complement, ones' complement, and signed magnitude. In the first
of these ~0 is equal to -1, but in the other two representations
the two quantities are unequal:
- In ones' complement ~0 is minus zero, which is numerically
equal to zero. `x = ~0' would be the same as `x = 0', and
would result in *no* bits set. (Or it could result in a
trap; see 6.2.6.2 paragraph 2.)
- In signed magnitude ~0 is minus INT_MAX. After the signed-
to-unsigned conversion `x = ~0' would be equivalent to
`x = UINT_MAX + 1 - INT_MAX'. With the typical assumption
that UINT_MAX == INT_MAX * 2u + 1u, the binary representation
of this value would be 0100...001 with exactly two 1-bits.
Conclusion: Use ~0 interchangeably with -1 if and only if you
are a masochist.
Seppo Citymarket
to
> unsigned is well-defined by the language specification.
Where is it defined? Quote? Paste here too!
Seppo Citymarket
> are a masochist.
Then let's look what "The C Programming Language" , 2nd edition has to say
about unary one's complement (~) operator.
2.9 Bitwise Operators, go to page 49, end of first paragraph says:
"The unary operator ~ yields the one's complement of an integer; that is, it
converts each 1-bit into a 0-bit and vice versa."
That's what Brian Kernighan and Dennis Ritchie have to say about ~ operator.
Now.. one's or two's complement, should not all bits of integer value zero
to be not set? Pay attention that I am saying zero, not negative zero. My
expression was:
~0, NOT ~-0 .. should then it follow logically, that if at first all bits
are zero, then inverted, that all bits would be ones? IMHO, Kernighan and
Ritchie were very verbose and clear about their intention. Your argument why
I was 'wrong' was cryptic and it was not very clear why value zero would be
suddenly interpreted as minus zero so that any what you say about hold under
closer inspection.
> Conclusion: Use ~0 interchangeably with -1 if and only if you
> are a masochist.
-1 is two's complement is different than in one's complement in "binary" if
you inspect the bits, so what follows logically is that I wouldn't use them
interchangeably! I even remember getting constant compiler warnings from
assigning negative value to unsigned integer, since I don't like compiler
warnings, I began using the ~0, 0xff, 0xffff or 0xffffffff when appropriate.
Heck, I never even implied that I would use them interchangeably at all.. I
wouldn't use the -1 format at all! ;-)
Jack Klein
<se...@citymarket.org> wrote in comp.lang.c:
ANSI/ISO/IEC 9899:1999, available from www.ansi.org or www.ntics.org
for $18.00 in Adobe PDF format for immediate download.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Jack Klein
<se...@citymarket.org> wrote in comp.lang.c:
> > Conclusion: Use ~0 interchangeably with -1 if and only if you
> > are a masochist.
>
> Then let's look what "The C Programming Language" , 2nd edition has to say
> about unary one's complement (~) operator.
Note that K&R2 has mistakes. Have you checked the errata? Also, this
book does not define the language, the ISO standard defines the
language.
> 2.9 Bitwise Operators, go to page 49, end of first paragraph says:
>
> "The unary operator ~ yields the one's complement of an integer; that is, it
> converts each 1-bit into a 0-bit and vice versa."
>
> That's what Brian Kernighan and Dennis Ritchie have to say about ~ operator.
> Now.. one's or two's complement, should not all bits of integer value zero
> to be not set? Pay attention that I am saying zero, not negative zero. My
> expression was:
Yes, applying the ~ operator to a signed int produces the 1's
complement of that int. Which may be a trap representation and invoke
undefined behavior because on 1's complement representations this
produces the signed int value -0, which is not required to be valid.
> ~0, NOT ~-0 .. should then it follow logically, that if at first all bits
> are zero, then inverted, that all bits would be ones? IMHO, Kernighan and
> Ritchie were very verbose and clear about their intention. Your argument why
> I was 'wrong' was cryptic and it was not very clear why value zero would be
> suddenly interpreted as minus zero so that any what you say about hold under
> closer inspection.
Obviously you have never read the ISO standard, which defines the
language, and know nothing about trap representations.
> > Conclusion: Use ~0 interchangeably with -1 if and only if you
> > are a masochist.
>
> -1 is two's complement is different than in one's complement in "binary" if
> you inspect the bits, so what follows logically is that I wouldn't use them
> interchangeably! I even remember getting constant compiler warnings from
> assigning negative value to unsigned integer, since I don't like compiler
> warnings, I began using the ~0, 0xff, 0xffff or 0xffffffff when appropriate.
Obviously you do not understand what you are talking about. The
standard specifically defines the results of assigning negative
integer constants to unsigned integer types. It is completely
defined, and defined in terms of VALUES, not in terms of bit
representations.
> Heck, I never even implied that I would use them interchangeably at all.. I
> wouldn't use the -1 format at all! ;-)
Then you risk invoking undefined behavior should your code ever be
compiled and executed on the few platforms that use 1's complement
representation.
Seppo Citymarket
> compiled and executed on the few platforms that use 1's complement
> representation.
Let me get this straight: one one's complement value zero is not
all-bits-zero? Yes? No? Then we can proceed.
Seppo Citymarket
Yes. There is no errate for ~ operator. Here is the URL for your
convenience, mr. super-human:
http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html
> Also, this book does not define the language, the ISO standard
> defines the language.
Oh, sorry, I thougt the title was "The C Programming Language" with [ANSI]
stamped diagonally over the letter C in the title. Where there isn't word
"ISO" in the newgroup name if this is NG about ISO C not ANSI C aswell.
> > "The unary operator ~ yields the one's complement of an integer; that
is, it
> > converts each 1-bit into a 0-bit and vice versa."
This still stands, prove me where even in the ISO C specification, maybe C99
as it is most recent version of the standard, that the unary operator ~ does
not do what it says above. Please feel free to prove me wrong instead of
assuming that "perhaps you don't this, perhaps you don't that".
Please DO show me where perhaps I am perhaps wrong perhaps! Shlong!
> Yes, applying the ~ operator to a signed int produces the 1's
> complement of that int. Which may be a trap representation and invoke
> undefined behavior because on 1's complement representations this
> produces the signed int value -0, which is not required to be valid.
Trap |!, (heh), how you propose zero in one's complement would be anything
BUT all-bits-zero. Please assume I am an idiot, spoon feed what bit pattern
in one's complement would equal to zero. I would love to see what you mean
by above when we put it into this context.
In advance I tell you: don't try to sneak -0 in, we are talking about 0. You
don't have to "educate" me why one's complement has positive and negative
zero, this I do know why. Just tell me why the zero without minus sign would
not be all-bits-zero. Don't try to sneak yourself out of this with witty
reply. Just answer the simple question.
> Obviously you have never read the ISO standard, which defines the
> language, and know nothing about trap representations.
Obviously you believe so, and I have no interest to convince you otherwise.
So tell me how "trap representations" would result in zero not being
all-bits-zero in binary? Consider as your chance to educate the people less
intelligent as you are.
> Obviously you do not understand what you are talking about. The
> standard specifically defines the results of assigning negative
> integer constants to unsigned integer types. It is completely
> defined, and defined in terms of VALUES, not in terms of bit
> representations.
That's fine, but the original poster wanted bit-pattern with all bits set to
one. ~0 in my opinion will result with all-bits-one with one's and two's
complement.
Obviously I am wrong, so feel free to enlighten me why. Let's begin by how
you would store "zero", value 0, in one's complement.
> Then you risk invoking undefined behavior should your code ever be
> compiled and executed on the few platforms that use 1's complement
> representation.
What the f***... since when ~ operator has been undefined for unsigned
integers? I can understand if you mean that the "type" of zero is not known
until assignment and that invokes undefined behaviour.
Would this be undefined in your definition aswell?
unsigned int v;
unsigned int u;
v = 0;
u = ~v;
Why is the above undefined? You sound like you just want to argue for the
sake or arguing man. Is this group really always like this? ;-)
pete
If you really want to use the ~ operator, you could use
unsigned int x = ~0u;
but without the 'u', then ~0 represents a bit pattern
which may or may not be allowed for type int, and ~0 is of type int.
--
pete
Seppo Citymarket
True, but value 0 is same if it's signed or unsigned so I don't see how this
could make any difference, when the result is written into unsigned integer.
Jack, Sosman, et al. have argued correctly, but with poor wording that for
certain architechtures (mainly 1's complement based) the SIGNED zero would
result in SIGNED all-bits-ones. They were trying to 'educate' me that this
"minus zero" might be not "supported" on some implementations of C, so the
result would be undefined.
What they lacked to take into consideration was that the original poster
wanted a bit-pattern with all-bits-set-to-one, for which all-bits-set-to-one
pattern would qualify nicely, even if not defined with SIGNED integers. We
wanted UNSIGNED integer, there it would be perfectly legal.
EVEN if the result is undefined, it's still all-bits-set-to-one by the
standard itself. This is the desired result, even if "undefined", it's still
what original poster was asking for.
That said, ~0u is indeed less ambiguous. They are nitpickers anyway & worth
killfiling. Plonk. (not you, you're cool & know what time it is ;-)
Hallvard B Furuseth
>>>> unsigned int x = -1;
>>>
>>> use ~0 in place of -1 to avoid any problems,
>>> does the same thing in same amount of typing.
>>
>> If you really want to use the ~ operator, you could use
>> unsigned int x = ~0u;
>> but without the 'u', then ~0 represents a bit pattern
>> which may or may not be allowed for type int, and ~0 is of type int.
>
> True, but value 0 is same if it's signed or unsigned so I don't see how this
> could make any difference, when the result is written into unsigned integer.
As someone else said, the C operators mostly define _values_ not _bit
patterns_. The _value_ of signed all-bits-one in one's complement is 0.
I.e on a one's complement machine, ~0 == 0. What bit representation the
implementation produces when your operation (~0) produces signed
all-bits-one is unspecified: Maybe it keeps it as all-bits-one and deals
with the problem later, or maybe it converts it to all-bits-zero at
once.
So this can be done before the ~0 is assigned to x, i.e. before the
compiler notices or cares that the result is to be unsigned.
However, this only applies to _signed_ values. ~0U is well-defined as
all-bits-one, because there is no sign anywhere to do one's complement
with.
However, it's still safer to get into the habit of using 'unsigned int x
= -1', or outside assignments: (unsigned int)-1 rather than ~0U. This
is because the ~0U trick breaks down for unsigned short/char:
~(unsigned char)0 gets promoted to ~(int)0 == ~0 == 0. OTOH,
(unsigned char)-1 is defined by the standard to mean UCHAR_MAX = typically
255.
So if you are going to deal with bit patterns, stick to positive values
(i.e. unsigned types or be very careful not to get a one in the sign
bit), or use the few cases where C does define how negative values work
- like when you convert a negative value to unsigned.
I suppose I should cite some Standard clauses, but I'm too lazy to find
them at the moment. You can buy the standard from ANSI at $18, or
find the latest draft at
<http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/>
Note that this is _not_ the standard; the standard has several
significant changes since that one, I don't think they changed
anything about this.
--
Hallvard
Hallvard B Furuseth
Seppo Citymarket <se...@citymarket.org> writes:
>>>> unsigned int x = -1;
>>>
>>> use ~0 in place of -1 to avoid any problems,
>>> does the same thing in same amount of typing.
>>
>> If you really want to use the ~ operator, you could use
>> unsigned int x = ~0u;
>> but without the 'u', then ~0 represents a bit pattern
>> which may or may not be allowed for type int, and ~0 is of type int.
>
> True, but value 0 is same if it's signed or unsigned so I don't see how this
> could make any difference, when the result is written into unsigned integer.
As someone else said, the C operators mostly define _values_ not _bit
patterns_. The _value_ of signed all-bits-one in one's complement is 0.
I.e on a one's complement machine, ~0 == 0. What bit representation the
implementation produces when your operation (~0) produces signed
all-bits-one is unspecified: Maybe it keeps it as all-bits-one and deals
with the problem later, or maybe it converts it to all-bits-zero at
once.
Anyway, 'unsigned int x = ~0u' assigns the _value 0_ to x on one's
complement machines. What the representation as signed int is doesn't
matter, the _value_ of ~0 is 0 there, and that's what x gets.
However, this only applies to _signed_ values. ~0U is well-defined as
all-bits-one, because there is no sign anywhere to do one's complement
with.
However, it's still safer to get into the habit of using 'unsigned int x
= -1', or outside assignments: (unsigned int)-1 rather than ~0U. This
is because the ~0U trick breaks down for unsigned short/char:
~(unsigned char)0 gets promoted to ~(int)0 == ~0 == 0. OTOH,
(unsigned char)-1 is defined by the standard to mean UCHAR_MAX = typically
255.
So if you are going to deal with bit patterns, stick to positive values
(i.e. unsigned types or be very careful not to get a one in the sign
bit), or use the few cases where C does define how negative values work
- like when you convert a negative value to unsigned.
I suppose I should cite some Standard clauses, but I'm too lazy to find
them at the moment. You can buy the standard from ANSI at $18, or
find the latest draft at
<http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/>
Note that this is _not_ the standard; the standard has several
significant changes since that one, I don't think they changed
anything about this.
--
Hallvard
--
Hallvard
Jack Klein
<se...@citymarket.org> wrote in comp.lang.c:
> > Note that K&R2 has mistakes. Have you checked the errata?
>
> Yes. There is no errate for ~ operator. Here is the URL for your
> convenience, mr. super-human:
>
> http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html
>
>
> > Also, this book does not define the language, the ISO standard
> > defines the language.
>
> Oh, sorry, I thougt the title was "The C Programming Language" with [ANSI]
> stamped diagonally over the letter C in the title. Where there isn't word
> "ISO" in the newgroup name if this is NG about ISO C not ANSI C aswell.
For most of the past 12+ years, the ANSI and ISO standards have been
identical. That was not the case in late 1999 and early 2000, for
example, when ANSI did not approve the standard update until about 7
months after it was approved by ISO.
> > > "The unary operator ~ yields the one's complement of an integer; that
> is, it
> > > converts each 1-bit into a 0-bit and vice versa."
>
> This still stands, prove me where even in the ISO C specification, maybe C99
> as it is most recent version of the standard, that the unary operator ~ does
> not do what it says above. Please feel free to prove me wrong instead of
> assuming that "perhaps you don't this, perhaps you don't that".
I never said that the ~ operator on an integer failed to produce the
1's complement of that integer. What I did say is that ~0 may be a
trap representation.
> Please DO show me where perhaps I am perhaps wrong perhaps! Shlong!
ANSI/ISO/IEC 9899:1999 6.2.6.1 paragraph 5:
<quote>
Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does
not have character type, the behavior is undefined. If such a
representation is produced by a side effect that modifies all or any
part of the object by an lvalue expression that does not have
character type, the behavior is undefined. Such a representation is
called a trap representation.
<unquote>
> > Yes, applying the ~ operator to a signed int produces the 1's
> > complement of that int. Which may be a trap representation and invoke
> > undefined behavior because on 1's complement representations this
> > produces the signed int value -0, which is not required to be valid.
>
> Trap |!, (heh), how you propose zero in one's complement would be anything
> BUT all-bits-zero. Please assume I am an idiot, spoon feed what bit pattern
> in one's complement would equal to zero. I would love to see what you mean
> by above when we put it into this context.
You could have just read the standard, as I suggested. From 6.2.6.2
paragraph 2:
<quote>
For signed integer types, the bits of the object representation shall
be divided into three groups: value bits, padding bits, and the sign
bit. There need not be any padding bits; there shall be exactly one
sign bit. Each bit that is a value bit shall have the same value as
the same bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type and N in
the unsigned type, then M £ N). If the sign bit is zero, it shall not
affect the resulting value. If the sign bit is one, the value shall be
modified in one of the following ways:
— the corresponding value with sign bit 0 is negated (sign and
magnitude);
— the sign bit has the value -(2 N )(two’s complement);
— the sign bit has the value -(2 N - 1) (one’s complement).
Which of these applies is implementation-defined, as is whether the
value with sign bit 1 and all value bits zero (for the first two), or
with sign bit and all value bits 1 (for one’s complement), is a trap
representation or a normal value. In the case of sign and
magnitude and one’s complement, if this representation is a normal
value it is called a negative zero.
<unquote>
Please pay close attention to the sentence "Which of these applies is
implementation-defined, as is whether the value with sign bit 1 and
all value bits zero (for the first two), or with sign bit and all
value bits 1 (for one’s complement), is a trap representation or a
normal value."
Now I hope we can agree that the numeric literal 0 in a C program has
type signed int. Furthermore we agree that such an int has all its
value bits, and its bit, binary 0. And we agree that the expression
~0 has all of its value bits and its sign bit all binary 1. If you
don't agree that the expression ~0 still has the type signed int,
there is no point in continuing this discussion, so I will assume you
agree that the expression ~0 is a signed int with all value bits, and
the sign bit, binary 1. Which is specifically what the sentence above
says may be a trap representation for a one's complement
implementation.
So on a one's complement platform, ~0 is either -0 or a trap
representation, unambiguously specified by the C standard.
> In advance I tell you: don't try to sneak -0 in, we are talking about 0. You
> don't have to "educate" me why one's complement has positive and negative
> zero, this I do know why. Just tell me why the zero without minus sign would
> not be all-bits-zero. Don't try to sneak yourself out of this with witty
> reply. Just answer the simple question.
I never said that the 0 without the minus sign would not be all bits
0, although under the current wording of the standard that is not
guaranteed. All that is required that all value bits and the sign bit
are 0. The value of padding bits, if there are any, are not required
to be 0.
> > Obviously you have never read the ISO standard, which defines the
> > language, and know nothing about trap representations.
>
> Obviously you believe so, and I have no interest to convince you otherwise.
> So tell me how "trap representations" would result in zero not being
> all-bits-zero in binary? Consider as your chance to educate the people less
> intelligent as you are.
You still fail to grasp that I am not talking about 0, but about ~0,
which still has type signed int.
> > Obviously you do not understand what you are talking about. The
> > standard specifically defines the results of assigning negative
> > integer constants to unsigned integer types. It is completely
> > defined, and defined in terms of VALUES, not in terms of bit
> > representations.
>
> That's fine, but the original poster wanted bit-pattern with all bits set to
> one. ~0 in my opinion will result with all-bits-one with one's and two's
> complement.
Yes indeed, the expression ~0 will result in a signed int value
containing all bits one in all three types of representation, 1's
complement, 2's complement, and signed magnitude. Which the standard
specifically states may be a trap representation for 1's complement
implementations.
> Obviously I am wrong, so feel free to enlighten me why. Let's begin by how
> you would store "zero", value 0, in one's complement.
>
>
> > Then you risk invoking undefined behavior should your code ever be
> > compiled and executed on the few platforms that use 1's complement
> > representation.
>
> What the f***... since when ~ operator has been undefined for unsigned
> integers? I can understand if you mean that the "type" of zero is not known
> until assignment and that invokes undefined behaviour.
I never said the ~ operator has been undefined for unsigned integers.
You have never talked about unsigned integers. Your original
statement, which you are trying fruitlessly to defend, was:
> use ~0 in place of -1 to avoid any problems, does the same thing in same
> amount of typing.
This was in response to Brian's original post with the sample code:
> unsigned int x = -1;
So I put the two together and assumed that you were telling Brian that
he should code this:
unsigned int x = ~0;
Just where is the ~ operator being applied to an unsigned integer?
The integer constant 0 has the type signed int. The expression "~0"
still has the type signed int. The fact that after evaluating this
expression you assign the result to an unsigned int does NOT change
the type of the expression.
> Would this be undefined in your definition aswell?
>
> unsigned int v;
> unsigned int u;
> v = 0;
> u = ~v;
No, this is well defined because the type of v is unsigned int, and
the ~ operator is well defined for unsigned int. In fact, had you
written "~0U", it would have been just as well defined, because you
would have been applying the ~ operator to an unsigned int value
producing an unsigned int result. But just plain ~0 applies the ~
operator to a signed int value and yields a signed int result, one
that the standard specifically states may be a trap value for one's
complement implementations.
> Why is the above undefined? You sound like you just want to argue for the
> sake or arguing man. Is this group really always like this? ;-)
Saving the best for last, here is a final excerpt from the standard,
one that addresses the issue even more directly. From 6.2.6.2
paragraph 4:
<quote>
If the implementation does not support negative zeros, the behavior of
the &, |, ^, ~, <<, and >> operators with arguments that would produce
such a value is undefined.
</quote>
Therefore if a one's complement "implementation does not support
negative zeros", producing one with the ~ operator with the expression
~0 specifically causes undefined behavior.
As to why people in this group are so argumentative, we prize accuracy
very highly here. You posted an answer to a question that was just
plain wrong. That in itself is not a problem, everyone who posts here
posts incorrectly at least some of the time, myself most certainly
included.
But several different people in several different parts of the thread
told you that you were wrong, and all you did was argue with them.
I posted that the standard contradicted you. A simple response of
"chapter and verse" would have been adequate. Anyone who claims the
standard supports his/her position in this group had better be
prepared to provide the relevant citations if challenged, as I have
done in excruciating detail here.
Richard Heathfield
>
> > > > unsigned int x = -1;
> > >
> > > use ~0 in place of -1 to avoid any problems,
> > > does the same thing in same amount of typing.
> >
> > If you really want to use the ~ operator, you could use
> > unsigned int x = ~0u;
> > but without the 'u', then ~0 represents a bit pattern
> > which may or may not be allowed for type int, and ~0 is of type int.
>
> True, but value 0 is same if it's signed or unsigned so I don't see how this
> could make any difference, when the result is written into unsigned integer.
By the time it's copied into the unsigned integer, it's too late. If the
bit pattern generated by ~0 is a trap representation for type int, then
merely *forming* that representation is enough to screw your program.
>
> Jack, Sosman, et al. have argued correctly, but with poor wording that for
> certain architechtures (mainly 1's complement based) the SIGNED zero would
> result in SIGNED all-bits-ones. They were trying to 'educate' me that this
> "minus zero" might be not "supported" on some implementations of C, so the
> result would be undefined.
>
> What they lacked to take into consideration was that the original poster
> wanted a bit-pattern with all-bits-set-to-one, for which all-bits-set-to-one
> pattern would qualify nicely, even if not defined with SIGNED integers. We
> wanted UNSIGNED integer, there it would be perfectly legal.
But their point is that if you get there via ~0, you could be generating
a trap representation, which means undefined behaviour (of which the
most likely manifestation in this case would probably be the halting of
the program).
>
> EVEN if the result is undefined, it's still all-bits-set-to-one by the
> standard itself. This is the desired result, even if "undefined", it's still
> what original poster was asking for.
No, I don't think it is. If there's a way that is guaranteed to work and
a way that is not guaranteed to work, I'll always choose the former.
Wouldn't you?
>
> That said, ~0u is indeed less ambiguous.
Right.
> They are nitpickers anyway & worth
> killfiling. Plonk.
You plonk people for correcting you? Well, that's probably going to save
them a lot of time in future, as they can correct you without fear of
your arguing about it. And you might as well plonk me while you're at
it, as I'm bound to pick a few nits off you at some point.
> (not you, you're cool & know what time it is ;-)
I'm relatively warm at present (summer, you see). It's 08:15.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Hallvard B Furuseth
> By the time it's copied into the unsigned integer, it's too late. If the
> bit pattern generated by ~0 is a trap representation for type int, then
> merely *forming* that representation is enough to screw your program.
Excuse me, I think this is wrong. ~0 looks like a is a valid operation
to me, I I think it just means that ~0 must produce the bit pattern
all-bits-zero.
To get all-bits-one on a host where that is a trap representation,
I think you must do something like
union { int si; unsigned int ui; } u;
u.ui = -1;
printf("%d\n", u.si);
--
Hallvard
Richard Heathfield
>
> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> > By the time it's copied into the unsigned integer, it's too late. If the
> > bit pattern generated by ~0 is a trap representation for type int, then
> > merely *forming* that representation is enough to screw your program.
>
> Excuse me, I think this is wrong. ~0 looks like a is a valid operation
> to me, I I think it just means that ~0 must produce the bit pattern
> all-bits-zero.
What makes you think ~0 must produce all-bits-zero? Chapter and verse,
please.
<snip>
Hallvard B Furuseth
>> Excuse me, I think this is wrong. ~0 looks like a is a valid operation
>> to me, I I think it just means that ~0 must produce the bit pattern
>> all-bits-zero.
>
> What makes you think ~0 must produce all-bits-zero? Chapter and verse,
> please.
I meant if all-bits-one is a trap representation.
I can see nothing which says ~0 can produce a trap representation, and
it seems pretty strange if it could. Just the same as I'd be pretty
surprised if -2 + 2 produced a trap representation.
Both have all-bits-one as the "natural" result on one's complement.
So I think that if all-bits-one is a trap representation on a one's
complement machine, the implementation must covert it to all-bits-
zero when it occurs as the result of a normal operation.
--
Hallvard
Dan Pop
Chapter and verse, please.
-1 is portable and works for *all* the unsigned integer types, ~0 is not,
because the value of this expression depends on the representation of the
signed integers.
To make it portable you have to replace it ~0u, but then it takes
more typing :-) And if you later make x unsigned long, you have to
remember to edit the initialiser, too.
So, -1 is the winning solution: fully portable and maintenance free.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>Tobias Oed <tob...@physics.odu.edu> scribbled the following:
>> Seppo Citymarket wrote:
>>>> unsigned int x = -1;
>>>
>>> use ~0 in place of -1 to avoid any problems, does the same thing in same
>>> amount of typing.
>
>> On my keyboard the ~ requires the shift key to be held down, the - doesn't.
>> I hate my terminal. On the other hand it's better than ??-.
>> Tobias.
>
>The C language does not define a keyboard layout.
Note that the previous poster wrote: "on *my* keyboard" (emphasis mine),
so please address his point and not your strawman.
>On a French keyboard
>you have to press the shift key to type numbers.
I somehow doubt that the proponent of ~0 uses a French keyboard. On a
typical Finnish keyboard layout, I think that ~ requires the Alt Gr shift
key, BTW.
>Perhaps then it would
>have to be something like:
>unsigned int x;
>x = -(x==x);
>Or does this invoke un{specifi,defin}ed behaviour?
Too much typing, the parentheses require the shift key on most keyboard
layouts and undefined behaviour (x has an indeterminate value when x==x
is evaluated). The meaning of the expression is not immediately obvious.
Dan Pop
>> > > unsigned int x = -1;
>> >
>> > use ~0 in place of -1 to avoid any problems,
>> > does the same thing in same amount of typing.
>>
>> If you really want to use the ~ operator, you could use
>> unsigned int x = ~0u;
>> but without the 'u', then ~0 represents a bit pattern
>> which may or may not be allowed for type int, and ~0 is of type int.
>
>True, but value 0 is same if it's signed or unsigned so I don't see how this
>could make any difference, when the result is written into unsigned integer.
The thing that you're missing, due to your ignorance, it that the
assignment operator doesn't copy a bit pattern from its RHS operand to
its LHS operand. It copies a *value*. If the concept is too difficult
for you to grasp, think about assigning a float to an int.
So, on a one's complement implementation, ~0 produces a representation of
the value zero (the representation commonly called -0). It is the value
zero that is assigned to x, which is not exactly what you want. Even
worse, the one's complement implementation is free to decree the -0
representation as a trap representation, instead of treating it as a valid
representation of zero. In which case, your code invokes undefined
behaviour.
OTOH ~0u is an unsigned int expression, that is guaranteed to evaluate to
UINT_MAX. This value is copied to x, which is exactly what you want.
That is, until the day when you redefine x as unsigned long :-)
To assign the -1 value to an unsigned variable, the value needs to be
first converted to the corresponding unsigned type, because it cannot
be represented as such. The standard guarantees that the result of the
conversion is the greatest value that can be represented by the unsigned
type. This is what makes -1 both portable and suitable for initialising
*any* unsigned type to all ones. Again, there is no bit-pattern copying
involved, although the operation can be seen as such on a two's complement
implementation where both operands have the same width.
If you're still unable to see the problems of ~0 in context, you're a
hopeless idiot.
Dan Pop
>Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
>> By the time it's copied into the unsigned integer, it's too late. If the
>> bit pattern generated by ~0 is a trap representation for type int, then
>> merely *forming* that representation is enough to screw your program.
>
>Excuse me, I think this is wrong. ~0 looks like a is a valid operation
>to me,
[#4] Some operators (the unary operator ~, and the binary
operators <<, >>, &, ^, and |, collectively described as
bitwise operators) are required to have operands that have
integer type. These operators return values that depend on
the internal representations of integers, and have
implementation-defined and undefined aspects for signed
types.
>I I think it just means that ~0 must produce the bit pattern
>all-bits-zero.
The standard disagrees:
[#4] The result of the ~ operator is the bitwise complement
of its (promoted) operand (that is, each bit in the result
is set if and only if the corresponding bit in the converted
operand is not set).
This rules out the possibility of ~0 producing the bit pattern all bits
zero, because it is explicitly required to produce the bit pattern all
bits one. And if this bit pattern happens to be a trap representation,
we have a problem.
>To get all-bits-one on a host where that is a trap representation,
>I think you must do something like
> union { int si; unsigned int ui; } u;
> u.ui = -1;
> printf("%d\n", u.si);
The evaluation of u.si results in undefined behaviour on such an
implementation.
Hallvard B Furuseth
--
Hallvard
pete
>
> > > > unsigned int x = -1;
> > >
> > > use ~0 in place of -1 to avoid any problems,
> > > does the same thing in same amount of typing.
> >
> > If you really want to use the ~ operator, you could use
> > unsigned int x = ~0u;
> > but without the 'u', then ~0 represents a bit pattern
> > which may or may not be allowed for type int, and ~0 is of type int.
>
> True, but value 0 is same if it's signed or unsigned
> so I don't see how this could make any difference,
> when the result is written into unsigned integer.
(0) isn't the subject here, (~0) is.
(~0) is of type int, with undefined value.
> perfectly legal.
> EVEN if the result is undefined,
If the result is undefined, then whatever happens after that,
isn't covered by the rules of C.
> They are nitpickers anyway & worth killfiling. Plonk.
> (not you, you're cool & know what time it is ;-)
http://tycho.usno.navy.mil/cgi-bin/xbmclock.xbm?zone=EST
I'm glad that I didn't annoy you, but
I learn a lot from those guys.
I don't always understand what they're trying to explain, but
when I get a sense that a number of those guys have
a similar point of view, contrary to mine,
then the best thing for me to do is to
lurk and think about it for a while.
--
pete
Dan Pop
>(~0) is of type int, with undefined value.
The value is implementation-defined, because the bit pattern of the
result is well defined and the representation of signed integers is
implementation-defined.
pete
>
> In <3D1856...@mindspring.com> pete <pfi...@mindspring.com> writes:
>
> >(~0) is of type int, with undefined value.
>
> The value is implementation-defined, because the bit pattern of the
> result is well defined and the representation of signed integers is
> implementation-defined.
Thank you.
--
pete
Joona I Palaste
popular, because of one thing: He hosts the complete show in a
completely neutral, platonic mood. He shows all kinds of funny videos
and tells all kinds of funny jokes and never once have we seen or heard
him even slightly smirk.
On comp.lang.c, we have our own answer to Markus Kajo... he's called
Dan Pop. Because of this I have a special kind of respect for Dan Pop.
Dan Pop <Dan...@ifh.de> scribbled the following:
> In <af7s9k$2k5$1...@oravannahka.helsinki.fi> Joona I Palaste <pal...@cc.helsinki.fi> writes:
>>Tobias Oed <tob...@physics.odu.edu> scribbled the following:
>>> Seppo Citymarket wrote:
>>>>> unsigned int x = -1;
>>>>
>>>> use ~0 in place of -1 to avoid any problems, does the same thing in same
>>>> amount of typing.
>>
>>> On my keyboard the ~ requires the shift key to be held down, the - doesn't.
>>> I hate my terminal. On the other hand it's better than ??-.
>>> Tobias.
>>
>>The C language does not define a keyboard layout.
> Note that the previous poster wrote: "on *my* keyboard" (emphasis mine),
> so please address his point and not your strawman.
That wasn't a direct counterargument. I did not mean Seppo was lying,
which he wasn't. I meant that "on my keyboard..." is useless as an
argument why some way of typing is better than some other way, because
there are different kinds of keyboards.
>>On a French keyboard
>>you have to press the shift key to type numbers.
> I somehow doubt that the proponent of ~0 uses a French keyboard. On a
> typical Finnish keyboard layout, I think that ~ requires the Alt Gr shift
> key, BTW.
~ requiring an Alt Gr key is all the more reason *not* to use the form
~0, which you'll see I was arguing.
>>Perhaps then it would
>>have to be something like:
>>unsigned int x;
>>x = -(x==x);
>>Or does this invoke un{specifi,defin}ed behaviour?
> Too much typing, the parentheses require the shift key on most keyboard
> layouts and undefined behaviour (x has an indeterminate value when x==x
> is evaluated). The meaning of the expression is not immediately obvious.
We can do away with the parantheses:
unsigned int x;
x = x==x;
x = -x;
On most American and British keyboards, the characters = and ; do not
require any modifier keys.
There's still the most important problem, though - the undefined
behaviour that you rightly mentioned. We shall deal with this problem
by using a static variable y:
static int y;
and then we can initialise x with:
x = y==y;
x = -x;
Because static variables are initialised to 0 there is no undefined
behaviour.
Your third argument "the meaning of the expression is not immediately
obvious" varies from human reader to human reader, so I won't need to
give an universal rebute of it.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"That's no raisin - it's an ALIEN!"
- Tourist in MTV's Oddities
Richard Heathfield
>
> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> >> Excuse me, I think this is wrong. ~0 looks like a is a valid operation
> >> to me, I I think it just means that ~0 must produce the bit pattern
> >> all-bits-zero.
> >
> > What makes you think ~0 must produce all-bits-zero? Chapter and verse,
> > please.
>
> I meant if all-bits-one is a trap representation.
>
> I can see nothing which says ~0 can produce a trap representation, and
> it seems pretty strange if it could.
I don't recall claiming that it could. I do recall claiming:
"If the bit pattern generated by ~0 is a trap representation for type
int, then merely *forming* that representation is enough to screw your
program."
The word "if" is rather important.
> Just the same as I'd be pretty
> surprised if -2 + 2 produced a trap representation.
So would I. :-)
>
> Both have all-bits-one as the "natural" result on one's complement.
> So I think that if all-bits-one is a trap representation on a one's
> complement machine, the implementation must covert it to all-bits-
> zero when it occurs as the result of a normal operation.
I think you're right that it /would/, but why do you say that it /must/?
Hallvard B Furuseth
>Hallvard B Furuseth wrote:
>
>> I can see nothing which says ~0 can produce a trap representation, and
>> it seems pretty strange if it could.
>
> I don't recall claiming that it could. I do recall claiming:
>
> "If the bit pattern generated by ~0 is a trap representation for type
> int, then merely *forming* that representation is enough to screw your
> program."
>
> The word "if" is rather important.
Well, I kind of assumed that since you mentioned it, you thought it
could happen. I thought it couldn't.
>> Both have all-bits-one as the "natural" result on one's complement.
>> So I think that if all-bits-one is a trap representation on a one's
>> complement machine, the implementation must covert it to all-bits-
>> zero when it occurs as the result of a normal operation.
>
> I think you're right that it /would/, but why do you say that it /must/?
Because I was wrong:-)
--
Hallvard
Dan Pop
>Dan Pop <Dan...@ifh.de> scribbled the following:
>> In <af7s9k$2k5$1...@oravannahka.helsinki.fi> Joona I Palaste <pal...@cc.helsinki.fi> writes:
>>>Tobias Oed <tob...@physics.odu.edu> scribbled the following:
>>>> Seppo Citymarket wrote:
>>>>>> unsigned int x = -1;
>>>>>
>>>>> use ~0 in place of -1 to avoid any problems, does the same thing in same
>>>>> amount of typing.
>>>
>>>> On my keyboard the ~ requires the shift key to be held down, the - doesn't.
>>>> I hate my terminal. On the other hand it's better than ??-.
>>>> Tobias.
>>>
>>>The C language does not define a keyboard layout.
>
>> Note that the previous poster wrote: "on *my* keyboard" (emphasis mine),
>> so please address his point and not your strawman.
>
>That wasn't a direct counterargument. I did not mean Seppo was lying,
>which he wasn't. I meant that "on my keyboard..." is useless as an
>argument why some way of typing is better than some other way, because
>there are different kinds of keyboards.
No, it's not useless. It is a subjective argument, but subjective
arguments have a great impact on our decisions, whether they are related
to C programming or to anything else.
That particular argument is valid to any keyboard layout where ~ is a
"shifted character" and all the keyboard layouts I'm familiar with fit the
bill. Of course, there may be people who love pressing the shift key...
>>>On a French keyboard
>>>you have to press the shift key to type numbers.
>
>> I somehow doubt that the proponent of ~0 uses a French keyboard. On a
>> typical Finnish keyboard layout, I think that ~ requires the Alt Gr shift
>> key, BTW.
>
>~ requiring an Alt Gr key is all the more reason *not* to use the form
>~0, which you'll see I was arguing.
The shift key argument was introduced in the discussion by Tobias Oed,
who seemed to be rather neutral to the usage of ~0.
>>>Perhaps then it would
>>>have to be something like:
>>>unsigned int x;
>>>x = -(x==x);
>>>Or does this invoke un{specifi,defin}ed behaviour?
>
>> Too much typing, the parentheses require the shift key on most keyboard
>> layouts and undefined behaviour (x has an indeterminate value when x==x
>> is evaluated). The meaning of the expression is not immediately obvious.
>
>We can do away with the parantheses:
>unsigned int x;
>x = x==x;
>x = -x;
>On most American and British keyboards, the characters = and ; do not
>require any modifier keys.
>There's still the most important problem, though - the undefined
>behaviour that you rightly mentioned. We shall deal with this problem
>by using a static variable y:
>static int y;
>and then we can initialise x with:
>x = y==y;
>x = -x;
>Because static variables are initialised to 0 there is no undefined
>behaviour.
You forgot to mention the advantages of this "improved" solution, versus
the "classic"
unsigned x = -1;
The only one I can see is that, on a French keyboard, it can be typed
without touching the shift key. But wait... on a German keyboard, typing
= requires the shift key and there are no less than 4 instances of it!
You also have several semicolons, and they require the shift key, too.
>Your third argument "the meaning of the expression is not immediately
>obvious" varies from human reader to human reader, so I won't need to
>give an universal rebute of it.
Do you suggest that there are human readers to whom x = -(x==x) is at
least as obvious as x = -1?
Dan
PS Despite apparent evidence to the contrary, I am not humour impaired :-)
Eric Sosman
>
> > Conclusion: Use ~0 interchangeably with -1 if and only if you
> > are a masochist.
>
> Then let's look what "The C Programming Language" , 2nd edition has to say
> about unary one's complement (~) operator.
>
>
> converts each 1-bit into a 0-bit and vice versa."
>
> Now.. one's or two's complement, should not all bits of integer value zero
> to be not set? Pay attention that I am saying zero, not negative zero. My
> expression was:
>
> are zero, then inverted, that all bits would be ones? IMHO, Kernighan and
> Ritchie were very verbose and clear about their intention. Your argument why
> I was 'wrong' was cryptic and it was not very clear why value zero would be
> suddenly interpreted as minus zero so that any what you say about hold under
> closer inspection.
What you've missed (I think) is that the conversion from signed
to unsigned is not defined in terms of bit patterns, but in terms of
values. Yes, `~0' produces a bit pattern consisting entirely of ones,
but the bit pattern isn't what matters: all that matters is the number
the bit pattern represents. It is clear that identical bit patterns
have different meanings in different representations; in particular,
the bit pattern consisting of all ones means:
- minus 1 in two's complement
- minus 0 in ones' complement (or a trap value, at the
implementation's discretion)
- minus INT_MAX in signed magnitude
When a negative integer value is converted to `unsigned int', the
result is *defined* (6.3.1.3 paragraph 2) to be the value obtained by
adding the quantity UINT_MAX+1 to the original value as many times as
needed to bring the result into the `unsigned int' range. (It is not
required that the implementation actually perform repeated additions,
but whatever shortcuts are used must produce the specified value.)
The three possible values of `~0' are converted as follows:
- two's complement: -1 + UINT_MAX+1 => UINT_MAX (since the
input and output bit patterns are identical in this case,
the "conversion" is particularly easy)
- ones' complement: -0 (if not a trap) => 0u
- signed magnitude: -INT_MAX + UINT_MAX+1 => an implementation-
defined quantity, usually looking like 0100...001 in binary.
Only the first of these values is "all-bits-set," which was the
original goal of the exercise.
> > Conclusion: Use ~0 interchangeably with -1 if and only if you
> > are a masochist.
>
> -1 is two's complement is different than in one's complement in "binary" if
> you inspect the bits, so what follows logically is that I wouldn't use them
> interchangeably! I even remember getting constant compiler warnings from
> assigning negative value to unsigned integer, since I don't like compiler
> warnings, I began using the ~0, 0xff, 0xffff or 0xffffffff when appropriate.
Permit me to suggest that you've chosen the wrong remedy: nothing
was broken, but you "fixed" it anyhow. Not only have you tied yourself
irrevocably to two's complement machines by using `~0', but the form of
your hexadecimal constant strongly suggests you've tied yourself to
machines with 8-bit bytes. 8-bit bytes have been around for quite
awhile, but pressures for change are already evident.
> Heck, I never even implied that I would use them interchangeably at all.. I
> wouldn't use the -1 format at all! ;-)
Conclusion: You are not only a masochist, but a stubborn masochist.
CBFalconer
>
... snip ...
>
> I can see nothing which says ~0 can produce a trap representation, and
> it seems pretty strange if it could. Just the same as I'd be pretty
> surprised if -2 + 2 produced a trap representation.
>
> Both have all-bits-one as the "natural" result on one's complement.
> So I think that if all-bits-one is a trap representation on a one's
> complement machine, the implementation must covert it to all-bits-
> zero when it occurs as the result of a normal operation.
No they don't necessarily. -2 + 2 produces all bits zero on a 1's
complement machine where the basic arithmetic unit is a
subtractor. The addition operation is implemented as 'complement
and subtract'. This frees up all bits one to be a trap
representation.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Seppo Citymarket
I was assuming that the zero was *unsigned* because of promotion to
different type, example in float:
float a;
float b;
a = 100;
b = 1 / a;
Is the 1 promoted to float? Or is integer one divided by 100? Is the result
1/100 or 0? I was thinking of similiar case for the ~0, further example:
a = 2;
b = 2.0f;
and..
a = 0;
b = 0.0f;
What is the difference between the two statements above? Will there be
runtime-conversion from integer zero to floating-point zero in assignment to
a? Or will the promotion to floating-point be done at compile time for the
constant zero? I always thought this promotion was done at *compile* time
and for expression if the value was promoted it would be floating-point
value. Compare to explicitly choosing the type..
a = 2U;
a = 2.0;
a = 2.0f;
Here promotion is not done, and compiler will issue warning about truncation
on certain assignments. So..
unsigned int v;
v = ~0;
I was assuming, seemingly falsely, that the 0 is promoted to unsigned
status. What does the standard say about assignment/expression type
promotion, I am not as expert on the Standard as I have gathered a little
practical experience which obviously is not enough to write correct code.
Help IS appreciated, I'm sure everyone is interested what is going on in
this expression.
Btw. I would agree on instant that this would be undefined:
int v;
v = ~0;
For the unsigned case, I'm not so sure yet - confirm to one way or another.
I always thought that:
unsigned int v;
v = ~0;
.. is very well defined, because unsigned can hold the all-bits-ones. Is the
promotion "denied" because RHS is completely unique expression from the LHS?
I don't really know. I am a newbie on C, but I done a little assembly on
68000 so I always "see" C code in 68000 assembly output in my head. I know
there are diffeferent architechtures C must be able to serve, so I would
love to be brought up-to-speed about practical misconceptions that I have
become to believe in as facts. Like like 1 / (float) -example.. I just grown
to believe that the 1 would be treated as 1.0f, is this completely false and
undefined? I should write 1.0f / (float) instead? Help!
Seppo Citymarket
>
> The value is implementation-defined, because the bit pattern of the
> result is well defined and the representation of signed integers is
> implementation-defined.
float v = 0;
.. what will be done with this? Is there runtime conversion from
floating-point to integer, or is the "conversion" done at compile time? Or
both are allowed by the Standard?
What about:
float v = 0.0f;
Runtime or compile time conversion?
What about:
float v = 0U;
Runtime or compile time conversion?
float v = 0U;
Warning or silent promotion?
I just want this cleared up, WHAT precisely Standard says about constants in
expressions (especially assignments), if it says anything.
Kevin Bracey
"Seppo Citymarket" <se...@citymarket.org> wrote:
> > Conclusion: You are not only a masochist, but a stubborn masochist.
>
> I was assuming that the zero was *unsigned* because of promotion to
> different type, example in float:
>
> float a;
> float b;
> a = 100;
> b = 1 / a;
>
> Is the 1 promoted to float?
Yes, but only because "a" is a float. It's nothing to do with the fact it's
being assigned to a float.
> Or is integer one divided by 100? Is the result
> 1/100 or 0? I was thinking of similiar case for the ~0, further example:
>
> a = 0;
> b = 0.0f;
>
> What is the difference between the two statements above?
The end result is the same.
> Will there be runtime-conversion from integer zero to floating-point zero
> in assignment to a?
No, the conversion is done at compile-time (well, not necessarily, but it is
pretty much required that such conversions can be performed at compile time
because of the standard's notion of a "constant-expression").
> Or will the promotion to floating-point be done at compile time for the
> constant zero? I always thought this promotion was done at *compile* time
> and for expression if the value was promoted it would be floating-point
> value.
The expression on the right-hand side is either of type "int" or of type
"float" in your two cases. In the first case, when you come to assign an int
to a float, it is automatically converted at compile time.
> unsigned int v;
> v = ~0;
>
> I was assuming, seemingly falsely, that the 0 is promoted to unsigned
> status.
You're assuming that the 0 "knows" it's going to end up in an unsigned
quantity, but that's not how it works. The expression on the right-hand side
is evaluated first, _then_ the result is converted to the destination type.
"0" is of type int, and ~0 is still of type int, with all bits reversed. This
is where the uncertainty comes in - ~0 only has the value you think it does
in a 2's complement machine. This int value is then converted to unsigned
as if by adding UINT_MAX+1 if necessary to bring it into range.
Now, ~0u is fine as "if the promoted type is an unsigned type, the expression
~E is equivalent to the maximum value representable in that type minus E", to
quote standard section 6.5.3.3.
> What does the standard say about assignment/expression type
> promotion, I am not as expert on the Standard as I have gathered a little
> practical experience which obviously is not enough to write correct code.
You've just got to think about how a naive computer would execute the code.
Things have to be done one step at a time. Expressions like "~0" don't
change their behaviour depending on the context they're being used in. No
matter whether you do
float x = ~0;
char x = ~0;
complex double x = ~0;
bool x = ~0;
struct blob x = ~0;
~0 is always worked out the same way first, then the int result is converted
to the destination type (giving a compile-time diagnostic in the final case).
Thus for something like:
float a = 1 / 3;
1 / 3 is calculated first *as an integer divide*, giving the result 0. That
0 is then converted to a float.
My compiler will normally warn about this ("lower precision in wider
context"), but generally it's up to you to remember to do something like:
float a = 1 / 3.0f;
--
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/
Eric Sosman
>
> > Conclusion: You are not only a masochist, but a stubborn masochist.
>
> I was assuming that the zero was *unsigned* because of promotion to
In `unsigned int x = ~0;' the `~0' portion of the expression
involves an `int' operand and produces an `int' result. This
result is then converted to `unsigned int' by the `=' operator,
but the conversion is of the already-computed `int' value. The
"eventual destination" doesn't affect how the "preliminary
results" are computed.
> [...] example in float:
>
> float a;
> float b;
> a = 100;
> b = 1 / a;
>
> Is the 1 promoted to float? Or is integer one divided by 100? Is the result
> 1/100 or 0? [...]
The result is zero, by the same principle as above. The
`/' operator has two `int' operands, so it performs an integer
division and produces `0' (an `int') as a result. This value
is then converted to `0.0' upon assignment to `b'.
> [...] I was thinking of similiar case for the ~0, further example:
>
> a = 2;
> b = 2.0f;
>
> and..
>
> a = 0;
> b = 0.0f;
>
> What is the difference between the two statements above? Will there be
> runtime-conversion from integer zero to floating-point zero in assignment to
> a? Or will the promotion to floating-point be done at compile time for the
> constant zero? I always thought this promotion was done at *compile* time
> and for expression if the value was promoted it would be floating-point
> value.
Point the first: It's impossible for a strictly-conforming
program to tell whether a value (more generally, any sub-expression
involving only constants) is computed at compile time or at run
time.
Point the second: No matter how the compiler chooses to implement
the expression, the end result must be the same (except for a few
cases involving things like floating-point exceptions). The compiler
may simplify `b = 1 / 100' to `b = 0.0', but it must not produce
`b = 0.01'.
> Compare to explicitly choosing the type..
>
> a = 2U;
> a = 2.0;
> a = 2.0f;
>
> Here promotion is not done, and compiler will issue warning about truncation
> on certain assignments. So..
You're using "promotion" in a strange way here. Conversion is
certainly done in all these cases, because the left-hand side is
an `int' and the three right-hand sides are `unsigned int', `double',
and `float'. It happens that the "conversion" from `unsigned int'
to `int' amounts to nothing but a copy for values within the range
for both types, but the type changes even if the bits don't. For
the other two examples it's almost certain that the bits also change;
2 and 2.0 and 2.0f have entirely different bit patterns on most
implementations.
> unsigned int v;
> v = ~0;
>
> I was assuming, seemingly falsely, that the 0 is promoted to unsigned
> status. [...]
The `0' remains an `int'. The result of `~0' is also an `int'.
This result value (whatever it is, and if it isn't a trap value)
is then converted to `unsigned int'.
> [...] I am a newbie on C, but I done a little assembly on
> 68000 so I always "see" C code in 68000 assembly output in my head.
If you continue with this approach you will never see C as
anything but a glorified assembler. The implicit trap is that you'll
find yourself writing code that's nominally C but that "knows too
much" about the underlying machine and cannot be transferred to some
other machine with reasonable effort. A famous quip says that "C
combines the power of assembler with the portability of assembler,"
and you'll discover the truth in this joke unless you make an effort
to shift your attention toward the meaning of the C code and away
from the meaning of the machine language your particular compiler
happens to generate from it.
If I had to sum up what to do about your apparent confusions in
a short phrase, I'd say you should *forget* about the bits and the
bytes and think instead about the values they represent.
> [...] I know
> there are diffeferent architechtures C must be able to serve, so I would
> love to be brought up-to-speed about practical misconceptions that I have
> become to believe in as facts. Like like 1 / (float) -example.. I just grown
> to believe that the 1 would be treated as 1.0f, is this completely false and
> undefined? I should write 1.0f / (float) instead? Help!
Here's where the word "promotion" actually makes sense. The
rules for the `/' operator specify what's to be done when the
operands have different types. In this case, the `int' value is
promoted to `float' so the "effective" operands will have the
same type (actually, the implementation is allowed to promote
both operands to `double' if it likes). This promotion requires
the `1' to be converted to `1.0f' (or to `1.0'), and then the
division is carried out in `float' (or `double') arithmetic. The
`1' is not "treated as" a floating-point number, it is converted
to a floating-point number.
Values, not bits!
Eric Sosman
>
> Seppo Citymarket wrote:
> >
> > float a;
> > float b;
> > a = 100;
> > b = 1 / a;
> >
> > Is the 1 promoted to float? Or is integer one divided by 100? Is the result
> > 1/100 or 0? [...]
>
> The result is zero, by the same principle as above. The
> `/' operator has two `int' operands, so it performs an integer
> division and produces `0' (an `int') as a result. This value
> is then converted to `0.0' upon assignment to `b'.
Oh, damn! I read too hastily, conflated bits and pieces of
different example snippets, and answered as if `a' were an `int' --
thus making utter hash of everything. My apologies.
Seppo Citymarket
> different example snippets, and answered as if `a' were an `int' --
> thus making utter hash of everything. My apologies.
No problem, I knew the moment I read what you meant & you been very helpful
and gave me new perspective to things which is far superior to the one I had
yesterday! Thanks!
Martin F.
>> unsigned int x = -1;
>
> use ~0 in place of -1 to avoid any problems, does the same thing in same
> amount of typing.
No no no! ~0 has a number of problems:
- ~0 has type int. This is a signed type. Signed integers can
have unfortunate behavior when used in bit-operations.
- If you assign ~0 to an object of type unsigned long, for
example, and long has more value bits than int, the result
will NOT have all value bits set.
You would have to write ~0UL. It is too easy to forget those
extra letters. So use -1 instead; it will always work fine with
unsigned types.
Martin
Martin F.
> - If you assign ~0 to an object of type unsigned long, for
> example, and long has more value bits than int, the result
> will NOT have all value bits set.
I have re-thought about this point, and I think I was wrong.
~0 will yield -1 on two's complement machines, won't it? In
this case, the assignment *will* work (but only because it is
the same as -1; so writing -1 directly is s still better). On
sign-magnitude machines the result of ~0 will be a negative
value, but not -1, so the assignment gives x the wrong value.
On ones' complement machines, ~0 is negative zero, which will
be converted to zero, won't it? If negative zeroes are
unsupported by the implementation, the behavior is undefined
(if I remember correctly). As you can see, this all creates
too much worries. The best is to avoid bit-operations on
signed integers.
Martin
Hallvard B Furuseth
>>>(~0) is of type int, with undefined value.
>>
>> The value is implementation-defined, because the bit pattern of the
>> result is well defined and the representation of signed integers is
>> implementation-defined.
>
> float v = 0;
>
> .. what will be done with this? Is there runtime conversion from
> floating-point to integer, or is the "conversion" done at compile time?
It doesn't matter. You are thinking too low-level. Because:
> Or both are allowed by the Standard?
Both are allowed by the Standard. All the Standard says is that the
result must be _as if_ the 0 is evaluated (as an int), and afterwards
the '=' is done and notices that it must convert to float.
If the compiler converts the 0 to 23.0 and the program subtracts 23.0
at run-time, that's standard-conformig too.
> What about:
>
> float v = 0.0f;
>
> Runtime or compile time conversion?
What conversion? Both are floats.
> What about:
>
> float v = 0U;
>
> Runtime or compile time conversion?
Who cares? See above.
> float v = 0U;
>
> Warning or silent promotion?
Huh? Why warn? Anyway, the Standard doesn't require a diagnostic
there, but the compiler is free to warn about anything at all if it
wants to.
--
Hallvard
Dan Pop
>Seppo Citymarket wrote:
>
>>> unsigned int x = -1;
>>
>> use ~0 in place of -1 to avoid any problems, does the same thing in same
>> amount of typing.
>
>No no no! ~0 has a number of problems:
> - ~0 has type int. This is a signed type. Signed integers can
> have unfortunate behavior when used in bit-operations.
> - If you assign ~0 to an object of type unsigned long, for
> example, and long has more value bits than int, the result
> will NOT have all value bits set.
>
>You would have to write ~0UL.
Which, of course, may fail to do the job properly if the object's
type is changed to unsigned long long.
>It is too easy to forget those
>extra letters. So use -1 instead; it will always work fine with
>unsigned types.
With *all* the unsigned types, both standard and extended.
Dan
pete
>
> > >(~0) is of type int, with undefined value.
> >
> > The value is implementation-defined, because the bit pattern of the
> > result is well defined and the representation of signed integers is
> > implementation-defined.
>
> float v = 0;
0 is int. It's converted to float,
>
> .. what will be done with this? Is there runtime conversion from
> floating-point to integer, or is the "conversion"
> done at compile time? Or both are allowed by the Standard?
I believe either time is allowed.
>
> What about:
>
> float v = 0.0f;
>
> Runtime or compile time conversion?
0.0f is float, therefore no conversion.
>
> I just want this cleared up,
> WHAT precisely Standard says about constants in
> expressions (especially assignments), if it says anything.
You don't really need anybody to read to you, do you?
http://home.att.net/~jackklein/c/standards.html
http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/
--
pete
Dan Pop
>Seppo Citymarket wrote:
>>
>> > >(~0) is of type int, with undefined value.
>> >
>> > The value is implementation-defined, because the bit pattern of the
>> > result is well defined and the representation of signed integers is
>> > implementation-defined.
>>
>> float v = 0;
>
>0 is int. It's converted to float,
>
>> .. what will be done with this? Is there runtime conversion from
>> floating-point to integer, or is the "conversion"
>> done at compile time? Or both are allowed by the Standard?
>
>I believe either time is allowed.
Translation and execution need not even be separate steps: think about
C interpreters.
>> What about:
>>
>> float v = 0.0f;
>>
>> Runtime or compile time conversion?
>
>0.0f is float, therefore no conversion.
There is a conversion occuring in translation phase 7, from the "0.0f"
token to the corresponding float value. Again, the "run time vs compile
time" question is ill posed, as long as no strictly conforming program
can tell the difference.
glen herrmannsfeldt
><se...@citymarket.org> writes:
(snip)
Given the current (non)popularity of ones-complement machines, I
think we could forgive people for not understanding them.
The last I knew where some CDC machines, which CERN probably had
some of. I would be interested to know if any other companies
made them since CDC.
I do remember when I first started using a PDP-10 asking someone
if it was twos-complement. I did use a CDC machine, but never in C.
-- glen
pete
>
> In <3D19A1...@mindspring.com> pete <pfi...@mindspring.com> writes:
>
> >Seppo Citymarket wrote:
> >>
> >> > >(~0) is of type int, with undefined value.
> >> >
> >> > The value is implementation-defined, because the bit
> >> > pattern of the
> >> > result is well defined and the representation of
> >> > signed integers is
> >> > implementation-defined.
> >>
> >> float v = 0;
> >
> >0 is int. It's converted to float,
> >
> >> .. what will be done with this? Is there runtime conversion from
> >> floating-point to integer, or is the "conversion"
> >> done at compile time? Or both are allowed by the Standard?
> >
> >I believe either time is allowed.
>
> Translation and execution need not even be separate steps: think about
> C interpreters.
>
> >> What about:
> >>
> >> float v = 0.0f;
> >>
> >> Runtime or compile time conversion?
> >
> >0.0f is float, therefore no conversion.
>
> There is a conversion occuring in translation phase 7, from the "0.0f"
> token to the corresponding float value.
"floating-point to integer" implies that OP is talking about
"usual arithmetic conversions"
--
pete
Dan Pop
>Given the current (non)popularity of ones-complement machines, I
>think we could forgive people for not understanding them.
I have never used a one's complement machine myself. This didn't
prevent me from understanding the one's complement representation.
>The last I knew where some CDC machines, which CERN probably had
>some of.
The last of them (a 7600) has been dumped, a couple of decades ago.
In favour of a large IBM mainframe installation (that was also dumped,
in the mid nineties). It's all documented by a photo show in the
corridor connecting the two buildings of the IT division.
Phil Tregoning
> [#4] The result of the ~ operator is the bitwise complement
> of its (promoted) operand (that is, each bit in the result
> is set if and only if the corresponding bit in the converted
> operand is not set).
>
> This rules out the possibility of ~0 producing the bit pattern all bits
> zero, because it is explicitly required to produce the bit pattern all
> bits one. And if this bit pattern happens to be a trap representation,
> we have a problem.
>
C99 also says this about the operators that can produce -0
(including ~):
It is unspecified whether these cases actually generate a negative
zero or a normal zero, and whether a negative zero becomes a normal
zero when stored in an object.
This seams to say ~0 is allowed to generate all-bits-zero on a ones
complement machine (even though that would contradict the passage you
quoted).
Phil T
glen herrmannsfeldt
>In <afd4lt$a...@gap.cco.caltech.edu> g...@ugcs.caltech.edu writes:
>>Given the current (non)popularity of ones-complement machines, I
>>think we could forgive people for not understanding them.
>I have never used a one's complement machine myself. This didn't
>prevent me from understanding the one's complement representation.
I might guess that you aren't typical, though.
I wouldn't be surprised if a large fraction of current CS graduates
didn't know what ones complement was, or that machines were ever
built that way.
>>The last I knew where some CDC machines, which CERN probably had
>>some of.
>The last of them (a 7600) has been dumped, a couple of decades ago.
>In favour of a large IBM mainframe installation (that was also dumped,
>in the mid nineties). It's all documented by a photo show in the
>corridor connecting the two buildings of the IT division.
That sounds about right. I don't think I used one until 1981,
(Cyber-174) though I don't think it stayed around long after that.
(I believe the B5500 was twos complement, though I am not sure.
That is, the first computer I used, when I was about 9 years old.)
-- glen
Richard Bos
> Dan...@ifh.de (Dan Pop) writes:
>
> >In <afd4lt$a...@gap.cco.caltech.edu> g...@ugcs.caltech.edu writes:
>
> >>Given the current (non)popularity of ones-complement machines, I
> >>think we could forgive people for not understanding them.
>
> >I have never used a one's complement machine myself. This didn't
> >prevent me from understanding the one's complement representation.
>
> I might guess that you aren't typical, though.
I suspect Dan is, in this respect at least, more typical than you think.
> I wouldn't be surprised if a large fraction of current CS graduates
> didn't know what ones complement was, or that machines were ever
> built that way.
A CS graduate who doesn't know what one's complement is (_not_ was - the
procedure still exists even if there are few 1c machines left!) does not
deserve his graduation paper. It's like a language graduate not knowing
what "thy" means.
Richard
Thomas Stegen
>
> A CS graduate who doesn't know what one's complement is (_not_ was - the
> procedure still exists even if there are few 1c machines left!) does not
> deserve his graduation paper. It's like a language graduate not knowing
> what "thy" means.
Warning to all employers. Do not hire CS graduates, 99% of them do not
deserve their graduation paper, they do not know ones complement.
(Never mind that it would take perhaps 10 minutes)
--
Thomas Stegen
http://www.geocities.com/thinkoidz
pete
>
> Richard Bos wrote:
>
> >
> > A CS graduate who doesn't know what one's complement is (_not_ was - the
> > procedure still exists even if there are few 1c machines left!) does not
> > deserve his graduation paper. It's like a language graduate not knowing
> > what "thy" means.
>
> Warning to all employers. Do not hire CS graduates, 99% of them do not
> deserve their graduation paper, they do not know ones complement.
>
> (Never mind that it would take perhaps 10 minutes)
Also,
university engineering courses tend to not concentrate
on teaching at the "nuts and bolts" level,
but rather at the "big picture, new theory, concept" level.
Only one of my electrical engineering classes was invloved with motors,
and the topic of lightbulbs never came up in any of my classes.
--
pete
Simon Biber
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote:
> I wouldn't be surprised if a large fraction of current
> CS graduates didn't know what ones complement was, or
> that machines were ever built that way.
I'd just like to butt in here, and point out that I'm currently studying
CS, and in the first year of the course (2001) we did a subject called
"Computer Systems Architecture", which clearly explained 2's complement,
1's complement and Sign/Magnitude encodings. (Not to mention BCD and
IEEE754 float/double encodings as well.)
If graduates have forgotten this stuff by the time they graduate, that's
another story :-)
--
Simon.