value bits
Thad Smith
> Assuming that you are operating with an appropriate type
> like: unsigned int;
> and that unsigned int is at least 32 bits wide
> The following would be legal, right?
>
> unsigned int i = 0;
>
> for(;i<32;++i)
> foo & (1<<i);
I don't understand the point of your question, but yes, assuming foo is
defined as an integral type, the code fragment would be defined for such
an implementation, although there is no observable behavior.
Thad
cody
> like: unsigned int;
> and that unsigned int is at least 32 bits wide
> The following would be legal, right?
>
> unsigned int i = 0;
>
> for(;i<32;++i)
> foo & (1<<i);
First, you cannot rely on int having 32 bits use the constant UINT_BITS
instead. Additionally it is recommended using unsigned types for bitwise
operations because setting the signbit could under circumstances result in a
trap-representation, that is, an invalid value.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
those who know me have no need of my name
>First, you cannot rely on int having 32 bits use the constant UINT_BITS
>instead.
that `constant' does not exist in the standard.
--
a signature
Zack Weinberg
sizeof (int) * CHAR_BIT is the value you want.
zw
Fergus Henderson
Not necessarily. That's the number of size bits. But as the subject line
says, the question here is about value bits. Remember that this value is
going to be used instead of 32 in the following loop:
for(;i<32;++i)
foo & (1<<i);
I think the value needed is the base-2 logarithm of INT_MAX, rounded down.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Hallvard B Furuseth
>>>First, you cannot rely on int having 32 bits use the constant UINT_BITS
>>>instead.
>>
>> that `constant' does not exist in the standard.
>
> sizeof (int) * CHAR_BIT is the value you want.
No, it isn't. That counts padding bits as well.
You could use IMAX_BITS(UINT_MAX) if you want (unless int has more than
3.2E+10 bits:-)
#define IMAX_BITS(m) ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \
+ (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))
--
Hallvard
Dan Pop
>> Assuming that you are operating with an appropriate type
>> like: unsigned int;
>> and that unsigned int is at least 32 bits wide
>> The following would be legal, right?
>>
>> unsigned int i = 0;
>>
>> for(;i<32;++i)
>> foo & (1<<i);
>
>First, you cannot rely on int having 32 bits
He doesn't rely on it, he assumes it. Big difference!
>use the constant UINT_BITS instead.
Where is this constant defined and why do you think it has any relevance
to the code under discussion?
>Additionally it is recommended using unsigned types for bitwise
>operations because setting the signbit could under circumstances result in a
>trap-representation, that is, an invalid value.
Because of this, the relevant value here is number of value bits in an
int, not an unsigned int. This value can be obtained by doing a
population count on INT_MAX.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Eric Sosman
>
> Assuming that you are operating with an appropriate type
> like: unsigned int;
> and that unsigned int is at least 32 bits wide
> The following would be legal, right?
>
> unsigned int i = 0;
>
> for(;i<32;++i)
> foo & (1<<i);
Wrong. `1' is a constant of type `int', not of type
`unsigned int'. `1u << 31' is well-defined (assuming
UINT_MAX >= 0xFFFFFFFF), but `1 << 31' may not be.
James Kuyper
> > Assuming that you are operating with an appropriate type
> > like: unsigned int;
> > and that unsigned int is at least 32 bits wide
> > The following would be legal, right?
> >
> > unsigned int i = 0;
> >
> > for(;i<32;++i)
> > foo & (1<<i);
>
Yes he can; he specified that as part of the premise for his question.
> ... use the constant UINT_BITS
> instead.
There is no such constant in the standard.
> ... Additionally it is recommended using unsigned types for bitwise
> operations because setting the signbit could under circumstances result in a
> trap-representation, that is, an invalid value.
Since when does 'unsigned int' fail to qualify as an unsigned type?
pete
>
> "cody" <dont.spam.m...@gmx.de> wrote in message
> news:<bo32bt$17iejs$1...@ID-176797.news.uni-berlin.de>...
> > > foo & (1<<i);
> > ... Additionally it is recommended using unsigned types for bitwise
> > operations because setting the signbit could under
> > circumstances result in a trap-representation,
> > that is, an invalid value.
>
> Since when does 'unsigned int' fail to qualify as an unsigned type?
(1<<i)
--
pete
Dan Pop
>"cody" <dont.spam.m...@gmx.de> wrote in message news:<bo32bt$17iejs$1...@ID-176797.news.uni-berlin.de>...
>> > Assuming that you are operating with an appropriate type
>> > like: unsigned int;
>> > and that unsigned int is at least 32 bits wide
>> > The following would be legal, right?
>> >
>> > unsigned int i = 0;
>> >
>> > for(;i<32;++i)
>> > foo & (1<<i);
>>
>> ... Additionally it is recommended using unsigned types for bitwise
>> operations because setting the signbit could under circumstances result in a
>> trap-representation, that is, an invalid value.
>
>Since when does 'unsigned int' fail to qualify as an unsigned type?
Since when is the type of 1 << i determined by the type of the right
operand?
Mantorok Redgormor
it is determined by the type of the left?
- nethlek
Dan Pop
>it is determined by the type of the left?
comp.std.c is an even worse substitute for consulting a C book than
comp.lang.c.
cody
Yes
Thad Smith
>
> Zack Weinberg wrote:
> > sizeof (int) * CHAR_BIT is the value you want.
>
> No, it isn't. That counts padding bits as well.
>
> You could use IMAX_BITS(UINT_MAX) if you want (unless int has more than
> 3.2E+10 bits:-)
>
> #define IMAX_BITS(m) ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \
> + (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))
Interesting macro. It only seems to work for values of m = 2**n-1,
though. Is it possible to have a similar macro that works for all
positive values, that yields a contant expression, given a constant
argument? It seems straight-forward if we can limit the length to
something small, but harder if the value can be very big.
Thad
--
comp.lang.c.moderated - moderation address: cl...@plethora.net
Hallvard B Furuseth
> Hallvard B Furuseth wrote:
>>
>> You could use IMAX_BITS(UINT_MAX) if you want (unless int has more than
>> 3.2E+10 bits:-)
>>
>> #define IMAX_BITS(m) \
>> ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \
>> + (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))
>
> Interesting macro. It only seems to work for values of m = 2**n-1,
> though.
Yes. UINT_MAX (and the other _MAXes) _are_ 2**n-1.
> Is it possible to have a similar macro that works for all positive
> values, that yields a contant expression, given a constant argument?
> (...)
Almost certainly not. Except for moderately small values, as you
mention.
--
Hallvard
James Kuyper
>
> Thad Smith wrote:
> > Hallvard B Furuseth wrote:
> >>
> >> You could use IMAX_BITS(UINT_MAX) if you want (unless int has more than
> >> 3.2E+10 bits:-)
> >>
> >> #define IMAX_BITS(m) \
> >> ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \
> >> + (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))
> >
> > Interesting macro. It only seems to work for values of m = 2**n-1,
> > though.
>
> Yes. UINT_MAX (and the other _MAXes) _are_ 2**n-1.
That's mandatory for the unsigned types, and for the INTN_MAX defined in
<inttypes.h>. It's not required for any of the other *_MAX macros.
In particular, it's certainly not required for DBL_MAX. :-)
--
James Kuyper
MODIS Level 1 Lead
Science Data Support Team
(301) 352-2150
Dan Pop
>> it is determined by the type of the left?
>
>Yes
If you cannot post the *correct and complete* answer, it's better not to
post at all.
cody
> >
> >Yes
>
> If you cannot post the *correct and complete* answer, it's better not to
> post at all.
maybe my answer wasn't cpomplete, but at least correct.
in an expression a<<b the type of the restult is determined by a, isn't it?
Hallvard B Furuseth
> If you cannot post the *correct and complete* answer, it's better not to
> post at all.
If you cannot post the correction when you say people are wrong, it's
better not to post at all.
--
Hallvard
Dan Pop
>Hallvard B Furuseth wrote:
>>
>> Thad Smith wrote:
>> > Hallvard B Furuseth wrote:
>> >>
>> >> You could use IMAX_BITS(UINT_MAX) if you want (unless int has more than
>> >> 3.2E+10 bits:-)
>> >>
>> >> #define IMAX_BITS(m) \
>> >> ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \
>> >> + (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))
>> >
>> > Interesting macro. It only seems to work for values of m = 2**n-1,
>> > though.
>>
>> Yes. UINT_MAX (and the other _MAXes) _are_ 2**n-1.
>
>That's mandatory for the unsigned types, and for the INTN_MAX defined in
><inttypes.h>. It's not required for any of the other *_MAX macros.
Wrong! It is mandatory for the macros corresponding to *all* the integer
types supported by the implementation. We have already discussed the
issue, but your mid term memory seems to be failing.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
CBFalconer
> >>
> >> Yes. UINT_MAX (and the other _MAXes) _are_ 2**n-1.
> >
> > That's mandatory for the unsigned types, and for the INTN_MAX
> > defined in <inttypes.h>. It's not required for any of the
> > other *_MAX macros.
>
> Wrong! It is mandatory for the macros corresponding to *all*
> the integer types supported by the implementation. We have
> already discussed the issue, but your mid term memory seems to
> be failing.
I guess that means that, for all <T> such that both signed <T> and
unsigned <T> exist, a reliable way of creating a mask for the most
sig. bit would be:
unsigned <T> mask = U<T>_MAX - <T>_MAX;
which is handy when doing left shifts of unsigned objects and
needing to record a carry out. That assumes it is mandated that
U<T>_MAX > <T>_MAX. I think we can imply this from the need for a
sign bit in the possible signed representations (1's, 2's,
sign/mag).
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Hallvard B Furuseth
> I guess that means that, for all <T> such that both signed <T> and
> unsigned <T> exist, a reliable way of creating a mask for the most
> sig. bit would be:
>
> unsigned <T> mask = U<T>_MAX - <T>_MAX;
That's the most significant _bits_. Signed <T> may have more padding
bits than unsigned <T>. For the most significant _bit_ of unsigned
<T>, I'll stick to U<T>_MAX/2 + 1.
> That assumes it is mandated that U<T>_MAX > <T>_MAX.
It is. C99 6.2.6.2 (Integer types) says that 'if there are M value bits
in the signed type and N in the unsigned type, then M <= N'. The value
bits here do not include the sign bit.
--
Hallvard
Dan Pop
>> >> it is determined by the type of the left?
>> >
>> >Yes
>>
>> If you cannot post the *correct and complete* answer, it's better not to
>> post at all.
>
>maybe my answer wasn't cpomplete, but at least correct.
Nope, you can't achieve correctness without completeness, here.
>in an expression a<<b the type of the restult is determined by a, isn't it?
Nope. It is determined by the type of a *after* the integral promotions
have been performed. If a is short, the type of a << b is NOT short, but
int.
James Kuyper
>
> In <boipet$1ec6l5$1...@ID-176797.news.uni-berlin.de> "cody" <dont.spam.m...@gmx.de> writes:
>
> >> >> it is determined by the type of the left?
> >> >
> >> >Yes
> >>
> >> If you cannot post the *correct and complete* answer, it's better not to
> >> post at all.
> >
> >maybe my answer wasn't cpomplete, but at least correct.
>
> Nope, you can't achieve correctness without completeness, here.
>
> >in an expression a<<b the type of the restult is determined by a, isn't it?
>
> Nope. It is determined by the type of a *after* the integral promotions
He did not say that the result type was the type of 'a', only that it
was determined by the type of 'a'. "the type of a *after* the integral
promotions have been performed" is determined by the type of 'a'.
Dan Pop
>Dan Pop wrote:
>>
>> In <boipet$1ec6l5$1...@ID-176797.news.uni-berlin.de> "cody" <dont.spam.m...@gmx.de> writes:
>>
>> >> >> it is determined by the type of the left?
>> >> >
>> >> >Yes
>> >>
>> >> If you cannot post the *correct and complete* answer, it's better not to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> post at all.
>> >
>> >maybe my answer wasn't cpomplete, but at least correct.
>>
>> Nope, you can't achieve correctness without completeness, here.
>>
>> >in an expression a<<b the type of the restult is determined by a, isn't it?
>>
>> Nope. It is determined by the type of a *after* the integral promotions
>> have been performed. ...
>
>He did not say that the result type was the type of 'a', only that it
>was determined by the type of 'a'. "the type of a *after* the integral
>promotions have been performed" is determined by the type of 'a'.
Why do you think I wrote "*correct and complete* answer" in my previous
post?
James Kuyper
I don't know. His answer was correct as it stood, and complete enough
for the context.
In any event, I was responding to your answer after he said "maybe my
answer wasn't cpomplete, but at least correct." To express an acceptance
of the correctness of his statement, but to reject the adequacy of it's
completeness, would have required a reply that said the equivalent of
"Yes, but you needed to say more ...". An answer that starts "Nope."
implies a failure to recognise the correctness of his statement.
cody
>
> Nope, you can't achieve correctness without completeness, here.
>
> >in an expression a<<b the type of the restult is determined by a, isn't
it?
>
> Nope. It is determined by the type of a *after* the integral promotions
> have been performed. If a is short, the type of a << b is NOT short, but
> int.
Right, but I didn't say the result type is of a's type I said it is
dependent of it.
The result is determined by a by the following conversion table:
I know you know that, but I will state it for correctness here:
char->int
short->int
int->int
unsigned int->unsigned int
But now my question is what is, when a is long? I didn't found anything in
the C standard saying about integral promotions when the expression contains
a long value. I only found that:
"[#3] Otherwise, the new type is signed and the value cannot
be represented in it; the result is implementation-defined."
In my knowlegde, this makes the expression 1L<<1 implementation-defined.
Maybe Iam stupid but this is how I understand it.
Hallvard B Furuseth
> I know you know that, but I will state it for correctness here:
>
> char->int
> short->int
You were right the first time. Now you are wrong.
char and short are converted to unsigned int if they do not fit in an int.
> But now my question is what is, when a is long? I didn't found anything in
> the C standard saying about integral promotions when the expression contains
> a long value. I only found that:
>
> "[#3] Otherwise, the new type is signed and the value cannot
> be represented in it; the result is implementation-defined."
That's ANSI , not integral promotions. You missed 3.2.1.2 #1: When a
value with integral type is converted to another integral type, if the
value can be represented by the new type, its value is unchanged.
That's sufficient for integral promotions, which do not concern the long
types. Integral promotions are in ANSI 3.2.1.1: char, short, int
bitfield, enum, and their signed & unsigned varieties, are converted to
int or unsigned int.
--
Hallvard
Dave Hansen
<h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:
>cody wrote:
>
>> I know you know that, but I will state it for correctness here:
>>
>> char->int
>> short->int
>
>You were right the first time. Now you are wrong.
>char and short are converted to unsigned int if they do not fit in an int.
I can imagine a system where char might not fit in an int
(sizeof(int)==1, plain char unsigned), but I cannot imagine a
reasonable system where short would not. Are there any such systems?
Regards,
-=Dave
--
Change is inevitable, progress is not.
Jeremy Yallop
> On 10 Nov 2003 19:15:17 +0100, Hallvard B Furuseth
><h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:
>
>>cody wrote:
>>
>>> I know you know that, but I will state it for correctness here:
>>>
>>> char->int
>>> short->int
>>
>>You were right the first time. Now you are wrong.
>>char and short are converted to unsigned int if they do not fit in an int.
>
> I can imagine a system where char might not fit in an int
> (sizeof(int)==1, plain char unsigned), but I cannot imagine a
> reasonable system where short would not. Are there any such systems?
The range of values of short is a subrange of the values of int on
every conforming implementation.
Jeremy.
Hallvard B Furuseth
> I can imagine a system where char might not fit in an int
> (sizeof(int)==1, plain char unsigned), but I cannot imagine a
> reasonable system where short would not. Are there any such systems?
Whoops, sorry. I thought of char which was unsigned, and then I thought
of unsigned short...
--
Hallvard
Wojtek Lerch
> CBFalconer wrote:
> > That assumes it is mandated that U<T>_MAX > <T>_MAX.
>
> It is. C99 6.2.6.2 (Integer types) says that 'if there are M value bits
> in the signed type and N in the unsigned type, then M <= N'. The value
> bits here do not include the sign bit.
Did you mean "It is" or "It isn't"? ;-)
U<T>_MAX and <T>_MAX can be equal.
James Kuyper
>
> In <clcm-2003...@plethora.net> James Kuyper <kuy...@saicmodis.com> writes:
>
> >Hallvard B Furuseth wrote:
> >> Yes. UINT_MAX (and the other _MAXes) _are_ 2**n-1.
> >
> >That's mandatory for the unsigned types, and for the INTN_MAX defined in
> ><inttypes.h>. It's not required for any of the other *_MAX macros.
>
> Wrong! It is mandatory for the macros corresponding to *all* the integer
> types supported by the implementation. We have already discussed the
> issue, but your mid term memory seems to be failing.
My memory has never been entirely reliable, which is why I rely heavily
on paper and electronics to remember things for me. However, that's not
relevant here. The most recent relevant thread appears to be:
<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&frame=right&rnum=31&thl=1144180172,1142891717,1142871284,1142841446,1142821261,1142761614,1142760483,1142480708,1142472922,1141891923,1141876901,1141855837&seekm=7de74269.0211280143.67926e9f%40posting.google.com#link39>
Having reviewed that thread, I remain unconvinced by your arguments. The
relevant points:
A) Section 6.2.6.1 allows most types, with a few exceptions, to have
trap representations, and says nothing about how many are allowed for
each type.
B) The standard explicitly states that if an integer type uses a
sign-magnitude representation, the bit pattern which would otherwise
represent -0 can be a trap representation instead. This is a trap
representation for which the fact that it's a trap representation is
determined entirely by value and sign bits. It makes no explicit
statement statement to say that this is the only such pattern.
C) I claim that in the absence of any other specifications, a signed
integer type can have as many trap representations as the implementor
wishes to define, so long as the corresponding TYPE_MAX and TYPE_MIN
meet meet their requirements, and every value from TYPE_MIN and TYPE_MAX
has at least one non-trap representation. In particular, TYPE_MAX could
be a value less than 2**N, with every bit pattern that would otherwise
represent a value >TYPE_MAX being defined as a trap representation. You
vigorously denied that point.
D) You claimed that because -0 is the only trap representation the
standard describes explicitly for signed integer types, they cannot have
any other trap representations. I never conceded this point, but I did
grow tired of trying to convince you otherwise.
E) You claimed that the bit pattern which would otherwise represent
-(2**N) can also be a trap representation. I conceded that point, since
it's fully consistent with my own claim (C), but I have trouble
reconciling it with your claim (D). Unlike -0, the standard says nothing
explicit about that possibilty.
Jun Woong
"Mantorok Redgormor" <net...@tokyo.com> wrote in message news:41ec7ac0.03111...@posting.google.com...
...
>
> i don't think a char can ever be equal to an int
>
It can be equal to an int.
...
> so sizeof(int) == 1 can't happen on a strictly conforming
> implementation
> because it would be equivalent in rank to a char and char is equal in
> rank
> to signed char and unsigned char, while int is greater in rank than a
> short
> which is greater in rank than char
6.2.5p8:
For any two integer types with the same signedness and different
integer conversion rank (see 6.3.1.1), the range of values of the
type with smaller integer conversion rank is a subrange of the
values of the other type.
SCHAR_MAX == CHAR_MAX == SHRT_MAX == INT_MAX
UCHAR_MAX == USHRT_MAX == UINT_MAX
sizeof(char) == 1 == sizeof(short) == sizeof(int)
What's wrong with this except that the "==" is used as an ordinary
mathematical operator and that some hosted implementations can have
some practical problems with UCHAR_MAX == UINT_MAX in the standard
library.
--
Jun, Woong (mycoboco at hanmail.net)
Info. and Comm. University
Douglas A. Gwyn
> so sizeof(int) == 1 can't happen on a strictly conforming
> implementation
> because it would be equivalent in rank to a char and char is equal in
> rank
Rank has nothing to do with size. sizeof(int) *can* be 1.
Fergus Henderson
>sizeof(int) == 1 can't happen on a strictly conforming implementation
>because it would be equivalent in rank to a char and char is equal in rank
>which is greater in rank than char
Rank != size. What about the case where sizeof(int) == 1 and sizeof(char) == 1
but "rankof"(int) > "rankof"(char)?
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Dan Pop
>Dan Pop wrote:
>>
>> In <3FAFB0C9...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>
>> >Dan Pop wrote:
>> >>
>> >> In <boipet$1ec6l5$1...@ID-176797.news.uni-berlin.de> "cody" <dont.spam.m...@gmx.de> writes:
>> >>
>> >> >> >> it is determined by the type of the left?
>> >> >> >
>> >> >> >Yes
>> >> >>
>> >> >> If you cannot post the *correct and complete* answer, it's better not to
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> >> post at all.
>> >> >
>> >> >maybe my answer wasn't cpomplete, but at least correct.
>> >>
>> >> Nope, you can't achieve correctness without completeness, here.
>> >>
>> >> >in an expression a<<b the type of the restult is determined by a, isn't it?
>> >>
>> >> Nope. It is determined by the type of a *after* the integral promotions
>> >> have been performed. ...
>> >
>> >He did not say that the result type was the type of 'a', only that it
>> >was determined by the type of 'a'. "the type of a *after* the integral
>> >promotions have been performed" is determined by the type of 'a'.
>>
>> Why do you think I wrote "*correct and complete* answer" in my previous
>> post?
>
>I don't know. His answer was correct as it stood, and complete enough
>for the context. ^^^^^^^^^^^^^^^^^^^
>^^^^^^^^^^^^^^^
No way! The context was a question posted by an obvious beginner.
It is highly unreasonable to expect the beginner in question to be aware
of the subtleties involved in a plain "yes" answer.
Dan Pop
>> >maybe my answer wasn't cpomplete, but at least correct.
>>
>> Nope, you can't achieve correctness without completeness, here.
>>
>> >in an expression a<<b the type of the restult is determined by a, isn't
>it?
>>
>> Nope. It is determined by the type of a *after* the integral promotions
>> have been performed. If a is short, the type of a << b is NOT short, but
>> int.
>
>
>Right, but I didn't say the result type is of a's type I said it is
>dependent of it.
>The result is determined by a by the following conversion table:
>
>I know you know that, but I will state it for correctness here:
>
>char->int
That's not necessarily correct. Plain char may get promoted to unsigned
int.
>short->int
>int->int
>unsigned int->unsigned int
How about unsigned char and unsigned short?
>But now my question is what is, when a is long? I didn't found anything in
>the C standard saying about integral promotions when the expression contains
>a long value. I only found that:
>
> "[#3] Otherwise, the new type is signed and the value cannot
> be represented in it; the result is implementation-defined."
The *obvious* place to look is the definition of the integral promotions:
2 The following may be used in an expression wherever an int or
unsigned int may be used:
- An object or expression with an integer type whose integer
conversion rank is less than the rank of int and unsigned int.
- A bit-field of type _Bool, int, signed int, or unsigned int.
If an int can represent all values of the original type, the
value is converted to an int; otherwise, it is converted to
an unsigned int. These are called the integer promotions.
All other types are unchanged by the integer promotions.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>In my knowlegde, this makes the expression 1L<<1 implementation-defined.
>Maybe Iam stupid but this is how I understand it.
Nope, there is nothing implementation-defined about 1L << 1: the type is
long and the value is 2.
James Kuyper
...
> so sizeof(int) == 1 can't happen on a strictly conforming
> implementation
> because it would be equivalent in rank to a char
How did you reach that conclusion? The standard clearly prohibits
rank(int)==rank(char). If they have the same size, representation, and
range, that doesn't mean that they're required, or even allowed, to
have the same rank.
cody
> >for the context. ^^^^^^^^^^^^^^^^^^^
> >^^^^^^^^^^^^^^^
>
> No way! The context was a question posted by an obvious beginner.
> It is highly unreasonable to expect the beginner in question to be aware
> of the subtleties involved in a plain "yes" answer.
I admit that my answer wasn't complete and I admit that I do not fully
understand integer promotions (see my questions a few posts ealier).
But it is true that in an expression like a<<b the resulting type depends on
the type of a, not on b. And when I say it is determined by a I don't mean
it is of type a but is depends on the type of a, you know what I mean :)
cody
> >
> >char->int
>
> That's not necessarily correct. Plain char may get promoted to unsigned
int.
Under what circumstances? Is it implementation defined?
> >short->int
> >int->int
> >unsigned int->unsigned int
>
> How about unsigned char and unsigned short?
>
> >But now my question is what is, when a is long? I didn't found anything
in
> >the C standard saying about integral promotions when the expression
contains
> >a long value. I only found that:
> >
> > "[#3] Otherwise, the new type is signed and the value cannot
> > be represented in it; the result is implementation-defined."
>
> The *obvious* place to look is the definition of the integral promotions:
>
> 2 The following may be used in an expression wherever an int or
> unsigned int may be used:
>
> - An object or expression with an integer type whose integer
> conversion rank is less than the rank of int and unsigned int.
>
> - A bit-field of type _Bool, int, signed int, or unsigned int.
>
> If an int can represent all values of the original type, the
> value is converted to an int; otherwise, it is converted to
> an unsigned int. These are called the integer promotions.
> All other types are unchanged by the integer promotions.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I seem to have overlooked the last sentence..
> >In my knowlegde, this makes the expression 1L<<1 implementation-defined.
> >Maybe Iam stupid but this is how I understand it.
Indeed, I was stupid ;)
Dan Pop
You haven't read it carefully enough. It provides other examples, too:
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.
However, these are the only trap representations involving only sign bit
and value bits allowed by 6.2.6.2.
>C) I claim that in the absence of any other specifications, a signed
>integer type can have as many trap representations as the implementor
>wishes to define, so long as the corresponding TYPE_MAX and TYPE_MIN
>meet meet their requirements, and every value from TYPE_MIN and TYPE_MAX
>has at least one non-trap representation. In particular, TYPE_MAX could
>be a value less than 2**N, with every bit pattern that would otherwise
>represent a value >TYPE_MAX being defined as a trap representation. You
>vigorously denied that point.
That's your logical fallacy. A more general section, 6.2.6.1 in our
case, cannot override a more specific section, 6.2.6.2 in our case.
It's not the first time you're making this silly mistake. Since 6.2.6.2
doesn't state any other exceptions, you can't use 6.2.6.1 to introduce
arbitrary exceptions to the text of 6.2.6.2.
Remain unconvinced, for all I care, but stop posting your misconceptions
as if they were proven facts.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Hallvard B Furuseth
> Did you mean "It is" or "It isn't"? ;-)
Ugh. Maybe I should read my own postings before letting them loose on
the world.
--
Hallvard
James Kuyper
>
> > >I know you know that, but I will state it for correctness here:
> > >
> > >char->int
> >
> > That's not necessarily correct. Plain char may get promoted to unsigned
> int.
>
> Under what circumstances? Is it implementation defined?
Whether or not it happens is defined by the standard, but depends upon
implementation-defined features. Specifically, the standard requires
that 'char' be promoted to 'unsigned int', if CHAR_MAX > INT_MAX. Of
course, that can only happen if char is unsigned, since SCHAR_MAX must
be <= INT_MAX.
cody
I understand. When the implementation defines that both int and char is say,
16 bit and char is unsigned then 'a'<<1 yields to unsigned int.
Dan Pop
>> > > >I know you know that, but I will state it for correctness here:
>> > > >
>> > > >char->int
>> > >
>> > > That's not necessarily correct. Plain char may get promoted to
>unsigned
>> > int.
>> >
>> > Under what circumstances? Is it implementation defined?
>>
>> Whether or not it happens is defined by the standard, but depends upon
>> implementation-defined features. Specifically, the standard requires
>> that 'char' be promoted to 'unsigned int', if CHAR_MAX > INT_MAX. Of
>> course, that can only happen if char is unsigned, since SCHAR_MAX must
>> be <= INT_MAX.
>
>I understand. When the implementation defines that both int and char is say,
>16 bit and char is unsigned then 'a'<<1 yields to unsigned int.
Nope, this can NEVER happen: the type of 'a' << 1 will *always* be int
and nothing else, but the expression may invoke undefined behaviour.
Clue: the type of 'a' is not affected by any property of the type char.
You may want to actually read the standard before continuing to post to
this newsgroup.
cody
say,
> >16 bit and char is unsigned then 'a'<<1 yields to unsigned int.
>
> Nope, this can NEVER happen: the type of 'a' << 1 will *always* be int
> and nothing else, but the expression may invoke undefined behaviour.
> Clue: the type of 'a' is not affected by any property of the type char.
>
> You may want to actually read the standard before continuing to post to
> this newsgroup.
Sorry, I forgot a char literal will always be int in C. I meant:
unsigned char a;
then a<<1 yields to unsigned int.
--
James Kuyper
> >B) The standard explicitly states that if an integer type uses a
> >sign-magnitude representation, the bit pattern which would otherwise
> >represent -0 can be a trap representation instead. This is a trap
> >representation for which the fact that it's a trap representation is
> >determined entirely by value and sign bits. It makes no explicit
> >statement statement to say that this is the only such pattern.
>
> You haven't read it carefully enough. It provides other examples, too:
>
> 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.
Yes, I read that, a long time ago. However, I'd forgotten that it
mentions one possibility for each of the three options, only two of
which represent -0.
> However, these are the only trap representations involving only sign bit
> and value bits allowed by 6.2.6.2.
That's your conclusion, not something which actually follows from the
words of 6.2.6.2.
...
> It's not the first time you're making this silly mistake. Since 6.2.6.2
> doesn't state any other exceptions, you can't use 6.2.6.1 to introduce
> arbitrary exceptions to the text of 6.2.6.2.
If 6.2.6.2 said something to restrict how many trap values were allowed,
I'd agree that it overrides 6.2.6.1. However, it doesn't; it merely
describes how valid representations are to be interpreted. It mentions
three cases where the possibility of a trap representation is of special
significance, including the only two cases where multiple repesentations
of a single value are possible.
> Remain unconvinced, for all I care, but stop posting your misconceptions
> as if they were proven facts.
I'll stop posting my understanding of the standard when someone
convinces me that it is a misconception. Please don't expect me to lie
or be quiet about what I believe to be the truth; I don't expect it of
you. I certainly don't expect you to stop spreading your own numerous
misconceptions around until someone actually convinces you that's what
they are. I wish you would, but I don't expect it.
Dan Pop
>Dan Pop wrote:
>>
>> In <clcm-2003...@plethora.net> James Kuyper <kuy...@saicmodis.com> writes:
>...
>> >B) The standard explicitly states that if an integer type uses a
>> >sign-magnitude representation, the bit pattern which would otherwise
>> >represent -0 can be a trap representation instead. This is a trap
>> >representation for which the fact that it's a trap representation is
>> >determined entirely by value and sign bits. It makes no explicit
>> >statement statement to say that this is the only such pattern.
>>
>> You haven't read it carefully enough. It provides other examples, too:
>>
>> 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.
>
>Yes, I read that, a long time ago. However, I'd forgotten that it
>mentions one possibility for each of the three options, only two of
>which represent -0.
>
>> However, these are the only trap representations involving only sign bit
>> and value bits allowed by 6.2.6.2.
>
>That's your conclusion, not something which actually follows from the
>words of 6.2.6.2.
It does. The section defines the rules, then specifies the allowed
exceptions. In the absence of these *explicit* exceptions, there would
be NO exceptions at all: 6.2.6.1, being more general, cannot introduce
any arbitrary exceptions here, period.
>> Remain unconvinced, for all I care, but stop posting your misconceptions
>> as if they were proven facts.
>
>I'll stop posting my understanding of the standard when someone
>convinces me that it is a misconception.
One committee member confirmed that 6.2.6.2 lists the complete list of
trap values involving only sign and value bits. And when Doug and I
agree on something... ;-)
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Sheldon Simms
> In <clcm-2003...@plethora.net> James Kuyper <kuy...@saicmodis.com> writes:
>
>>Dan Pop wrote:
>>>
>>> However, these are the only trap representations involving only sign bit
>>> and value bits allowed by 6.2.6.2.
>>
>>That's your conclusion, not something which actually follows from the
>>words of 6.2.6.2.
>
> It does. The section defines the rules, then specifies the allowed
> exceptions. In the absence of these *explicit* exceptions, there would
> be NO exceptions at all: 6.2.6.1, being more general, cannot introduce
> any arbitrary exceptions here, period.
>
> One committee member confirmed that 6.2.6.2 lists the complete list of
> trap values involving only sign and value bits.
I don't disagree that that is the intent of the standard, but I don't
see how the language in the standard backs up your assertions. Where
in 6.2.6.2 does the standard state that a negative zero trap
representation is an exception to a rule?
6.2.6.1#5 states
Certain object representations need not represent a value of the object
type. ... Such a representation is called a trap representation.
What would be nonconforming about an implementation in which:
CHAR_BIT = 8
sizeof int = 4
INT_MIN = -50000
INT_MAX = 50000
and every bit pattern in the 4 contiguous bytes of an int object
which might otherwise represent numbers > 50000 or < -50000 are
in fact trap representations?
Dan Pop
>On Thu, 13 Nov 2003 23:05:39 +0000, Dan Pop wrote:
>
>> In <clcm-2003...@plethora.net> James Kuyper <kuy...@saicmodis.com> writes:
>>
>>>Dan Pop wrote:
>>>>
>>>> However, these are the only trap representations involving only sign bit
>>>> and value bits allowed by 6.2.6.2.
>>>
>>>That's your conclusion, not something which actually follows from the
>>>words of 6.2.6.2.
>>
>> It does. The section defines the rules, then specifies the allowed
>> exceptions. In the absence of these *explicit* exceptions, there would
>> be NO exceptions at all: 6.2.6.1, being more general, cannot introduce
>> any arbitrary exceptions here, period.
>>
>> One committee member confirmed that 6.2.6.2 lists the complete list of
>> trap values involving only sign and value bits.
>
>I don't disagree that that is the intent of the standard, but I don't
>see how the language in the standard backs up your assertions. Where
>in 6.2.6.2 does the standard state that a negative zero trap
>representation is an exception to a rule?
Remove the underlined text from the following quote:
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And the meaning of the corresponding bit patterns is negative zero
for one's complement and sign-magnitude or type_MIN for two's
complement, according to the rest of the section.
Therefore, this text introduces an exception.
>6.2.6.1#5 states
> Certain object representations need not represent a value of the object
> type. ... Such a representation is called a trap representation.
>
>What would be nonconforming about an implementation in which:
>
> CHAR_BIT = 8
> sizeof int = 4
> INT_MIN = -50000
> INT_MAX = 50000
>
>and every bit pattern in the 4 contiguous bytes of an int object
>which might otherwise represent numbers > 50000 or < -50000 are
>in fact trap representations?
The meanings of these bit patterns are defined by 6.2.6.2 and you
can't use a more generic paragraph to alter them. All the aspects that
are implementation-defined for the representation of integer types are
explicitly mentioned in 6.2.6.2. There is no way to turn something
that is defined by the standard into something implementation-defined
and still be conforming.
You can apply 6.2.6.1#5 freely to other types, whose representation is
left unspecified by the standard, or to the padding bits of the integer
types, but not to the value bits and sign bit of the integer types.
Once you start overriding more specific sections by more generic ones,
the result is complete chaos.
Sheldon Simms
> In <pan.2003.11.13....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>
>>6.2.6.1#5 states
>> Certain object representations need not represent a value of the object
>> type. ... Such a representation is called a trap representation.
>>
>>What would be nonconforming about an implementation in which:
>>
>> CHAR_BIT = 8
>> sizeof int = 4
>> INT_MIN = -50000
>> INT_MAX = 50000
>>
>>and every bit pattern in the 4 contiguous bytes of an int object
>>which might otherwise represent numbers > 50000 or < -50000 are
>>in fact trap representations?
>
> The meanings of these bit patterns are defined by 6.2.6.2 and you
> can't use a more generic paragraph to alter them. All the aspects that
> are implementation-defined for the representation of integer types are
> explicitly mentioned in 6.2.6.2. There is no way to turn something
> that is defined by the standard into something implementation-defined
> and still be conforming.
I'm going to offer a hypothetical implementation and then try to
show that it meets all requirements of 5.2.4.2.1 and 6.2.6.2 even
though a valid value can be changed into a trap representation by
changing one value bit. In the following a 'v' represents a value
bit, an 's' represents the sign bit and a '-' represents a padding
bit.
As in the last post:
CHAR_BIT == 8
sizeof(int) == 4
In this implementation there will be 17 value bits for both int and
unsigned int. The values will be represented in normal twos complement
fashion, with unusual values for INT_MAX and INT_MIN:
6.2.6.2#1 states:
For unsigned integer types other than unsigned char, the bits of the
object representation shall be divided into two groups: value bits and
padding bits ... If there are N value bits, each bit shall represent a
different power of 2 between 1 and 2N-1, so that objects of that type
shall be capable of representing values from 0 to 2N - 1 using a pure
binary representation;
Given 17 value bits, unsigned int must look like this:
---------------vvvvvvvvvvvvvvvvv
3 1 0
1 6 0
#define UINT_MAX 131071
6.2.6.2#2 states:
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
This requirement is satisfied by the following representation of int:
s--------------vvvvvvvvvvvvvvvvv
3 1 0
1 6 0
Arithmetic operations on this type will work exactly like normal 32-bit
twos complement operations. The only difference is:
#define INT_MIN -50000
#define INT_MAX 50000
Any value outside of this range is considered an overflow and its
representation a trap representation.
6.2.6.2#2 continues:
[It is implementation-defined] whether the value with sign bit 1 and all
value bits zero ... is a trap representation or a normal value.
In this sample implementation, such a value shall be a trap representation.
6.2.6.2#3 and 6.2.6.2#4 concern negative zero, which is not present in
this implementation. 6.2.6.2#5 states:
The values of any padding bits are unspecified.(45)
The footnote, although not normative, states:
45) Some combinations of padding bits might generate trap
representations, for example, if one padding bit is a parity bit.
In this example, it is not the value of the parity bit itself that makes
a trap representation, rather it is the value of the parity bit given the
values of the value bits.
Similarly in this hypothetical representation, if the sign bit is zero,
then any padding bit with the value one shall generate a trap
representation. If the sign bit is one, then any padding bit with the
value zero shall generate a trap representation. The footnote continues:
Regardless, no arithmetic operation on valid values can generate a
trap representation other than as part of an exceptional condition
such as an overflow.
Overflow is exactly the condition that generates trap representations by
way of arithmetic operations on valid values in this representation. The
footnote continues:
All other combinations of padding bits are alternative object
representations of the value specified by the value bits.
There are no such other combinations of padding bits in this
representation. 6.2.6.2#5 continues:
A valid (non-trap) object representation of a signed integer type where
the sign bit is zero is a valid object representation of the
corresponding unsigned type, and shall represent the same value.
This requirement is met by the hypothetical representation. It is
important to note that, given a valid object representation of an unsigned
integer type in which:
- value bits of the unsigned integer type that are not value bits
in the corresponding signed integer type are zero
- value bits of the unsigned integer type that are value bits in
the corresponding signed integer type are either one or zero.
there is no requirement that such a representation is also a valid object
representation of the corresponding signed type. It is therefore not
necessary that the object representation of the unsigned int value 50001
be a valid object representation of type int.
6.2.6.2#6 defines the precision and width of integer types and imposes no
requirements on their representations.
In this hypothetical representation, the value 50000 is a valid value of
type int and is represented 0x0000C350. The value 50001 is a trap
representation with the bit pattern 0x0000C351 - a difference of one value
bit.
Dan Pop
You're violating 6.2.6.2, which assigns a well defined value to *any*
pattern of value bits, as long as s = 0, and also specifies *all* the
possible behaviours when s = 1. Your implementation is non-conforming.
Try to read the following two paragraphs (and the definition of pure
binary representation from another footnote) carefully, until their
meaning sinks in:
6.2.6.2 Integer types
1 For unsigned integer types other than unsigned char, the bits
of the object representation shall be divided into two groups:
value bits and padding bits (there need not be any of the
latter). If there are N value bits, each bit shall represent
a different power of 2 between 1 and 2**(N-1), so that objects of
that type shall be capable of representing values from 0 to 2**N - 1
using a pure binary representation; 40) this shall be known as
the value representation. The values of any padding bits are
unspecified.
2 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.
____________________
40) A positional representation for integers that uses the binary
digits 0 and 1, in which the values represented by successive
bits are additive, begin with 1, and are multiplied
by successive integral powers of 2, except perhaps the
bit with the highest position. (Adapted from the American
National Dictionary for Information Processing Systems.) A
byte contains CHAR_BIT bits, and the values of type unsigned
char range from 0 to 2**CHAR_BIT - 1.
By violating the underlined "shall" above, your implementaion is
non-conforming.
Sheldon Simms
> In <pan.2003.11.14....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>
>>Arithmetic operations on this type will work exactly like normal 32-bit
>>twos complement operations. The only difference is:
>>
>>#define INT_MIN -50000
>>#define INT_MAX 50000
>>
>>Any value outside of this range is considered an overflow and its
>>representation a trap representation.
>
> You're violating 6.2.6.2, which assigns a well defined value to *any*
> pattern of value bits, as long as s = 0,
Wrong. 6.2.6.2 assigns no value at all to patterns of value bits.
6.2.6.2 assigns values to individual bits themselves.
> Try to read the following two paragraphs (and the definition of pure
> binary representation from another footnote) carefully, until their
> meaning sinks in:
>
> 6.2.6.2 Integer types
>
> 1 For unsigned integer types other than unsigned char, the bits
> of the object representation shall be divided into two groups:
> value bits and padding bits (there need not be any of the
> latter).
---------------vvvvvvvvvvvvvvvvv
3 1 0
1 6 0
This requirement is conformed with.
> If there are N value bits, each bit shall represent
> a different power of 2 between 1 and 2**(N-1), so that objects of
> that type shall be capable of representing values from 0 to 2**N - 1
> using a pure binary representation;
The rightmost value bit in the diagram above has the value 2**0 == 1.
The leftmost value bit in the diagram above has the value 2**16 == 65536.
Each other value bit has a value twice that of the value bit to its
right. There are 17 value bits in the representation, and the values
representable range from 0 to 131071. i.e., 0 to 2**N-1.
This requirement is conformed with.
> 40) this shall be known as the value representation.
> The values of any padding bits are unspecified.
>
> 2 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;
s--------------vvvvvvvvvvvvvvvvv
3 1 0
1 6 0
This requirement is conformed with
> there shall be exactly one sign bit.
This requirement is conformed with
> 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
The rightmost value bit in the diagram above has the value 2**0 == 1.
The leftmost value bit in the diagram above has the value 2**16 == 65536.
Each other value bit has a value twice that of the value bit to its
right.
The requirement is only that each BIT have the same value, not
that every pattern of value bits has the same value in the signed
type as the same pattern in the unsigned type.
Each value bit in this representation has EXACTLY the same value as
the same bit in the object representation of the unsigned type.
This is demonstrated by looking at the bit representation of the
value -32768.
-32768 is represented with a set sign bit and value bits
11000000000000000. The leftmost bit is set and has the value
2**16 == 65536, as required. The other set bit has the value
2**15 == 32768, as required. The sign bit has the value
-(2**N) == -131072, as required (see below). The sum of these bits is
65536+32768-131072 == -32768, as required.
This requirement is conformed with.
> (if there are M value bits in the signed type and N in the
> unsigned type, then M <= N).
in this representation M == N == 17
This requirement is conformed with.
> If the sign bit is zero, it shall not affect the resulting value.
This requirement is conformed with.
> 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);
In this representation, there is one sign bit. It has the value
-131072. When the sign bit is set, values of the value bits in the
range 10011110010110000 to 11111111111111111 (0x13cb0 - 0x1ffff)
are valid (non trap-representations) and, after adding the value
of the sign bit, represent integer values in the range -50000 to -1.
This requirement is conformed with.
> By violating the underlined "shall" above, your implementaion is
> non-conforming.
As above, the "shall" is speaking of the values that BITS shall have,
not the values of patterns of bits. In my representation, every bit
has the required value. The implementation is conforming.
-Sheldon
Dan Pop
>On Mon, 17 Nov 2003 12:01:59 +0000, Dan Pop wrote:
>
>> In <pan.2003.11.14....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>>
>>>Arithmetic operations on this type will work exactly like normal 32-bit
>>>twos complement operations. The only difference is:
>>>
>>>#define INT_MIN -50000
>>>#define INT_MAX 50000
>>>
>>>Any value outside of this range is considered an overflow and its
>>>representation a trap representation.
>>
>> You're violating 6.2.6.2, which assigns a well defined value to *any*
>> pattern of value bits, as long as s = 0,
>
>Wrong. 6.2.6.2 assigns no value at all to patterns of value bits.
>6.2.6.2 assigns values to individual bits themselves.
Wrong. You're ignoring footnote 40, which I have quoted in my previous
post. I have told you to read my quotes until they sink in, but,
unfortunately, you ignored the advice.
40) A positional representation for integers that uses the binary
digits 0 and 1, in which the values represented by successive
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bits are additive, begin with 1, and are multiplied
^^^^^^^^^^^^^^^^^
by successive integral powers of 2, except perhaps the
bit with the highest position. (Adapted from the American
National Dictionary for Information Processing Systems.)
Dan
Sheldon Simms
My representation implements this requirement completely. For example,
49000 is represented as 0--- ---- ---- ---0 1011 1111 0110 1000.
Starting from the right and moving left, the set bits have values
8,32,64,256,512,1024,2048,4096,8192,32768. The sum of these value
bits is 49000.
This is a pure binary representation.
There is absolutely no requirement for signed int that a particular
bit pattern represent a valid value, apart from the specifications of
INT_MIN and INT_MAX.
-Sheldon
James Kuyper
>
> On Mon, 17 Nov 2003 17:59:23 +0000, Dan Pop wrote:
> > 40) A positional representation for integers that uses the binary
> > digits 0 and 1, in which the values represented by successive
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > bits are additive, begin with 1, and are multiplied
> > ^^^^^^^^^^^^^^^^^
> > by successive integral powers of 2, except perhaps the
> > bit with the highest position. (Adapted from the American
> > National Dictionary for Information Processing Systems.)
>
> My representation implements this requirement completely. For example,
> 49000 is represented as 0--- ---- ---- ---0 1011 1111 0110 1000.
> Starting from the right and moving left, the set bits have values
> 8,32,64,256,512,1024,2048,4096,8192,32768. The sum of these value
> bits is 49000.
>
> This is a pure binary representation.
>
> There is absolutely no requirement for signed int that a particular
> bit pattern represent a valid value, apart from the specifications of
> INT_MIN and INT_MAX.
Everything you've said is something I said to him the last time we went
through this, with different wording. I doubt it will change his mind.
There's something in his way of reading those sentences that causes him
to see more restrictions than you or I do. I'd recommend breaking off
this conversation; it isn't really going anywhere. Every once in a while
I break down and actually respond to one of his messages, but it's
usually a very frustrating excercise, and I usually quickly decide
"never again" ... until the next time he says something I can't resist
correcting.
Dan Pop
>Everything you've said is something I said to him the last time we went
>through this, with different wording. I doubt it will change his mind.
It would take a lot more than two people who can't read a definition to
change my mind.
>There's something in his way of reading those sentences that causes him
>to see more restrictions than you or I do.
The definition of pure binary representation is crystal clear and there
is no way to introduce exceptions into it by quoting 6.2.6.1, a more
generic paragraph.
But these are things you cannot understand...
Dan Pop
Of course there is, and it is quoted right above. The things you don't
get are:
1. Definitions work both ways.
2. Definitions leave no place for arbitrary exceptions not explicitly
stated.
Therefore, according to the above definition, the value corresponding to
the bit pattern:
0--- ---- ---- ---1 1111 1111 1111 1111
is 2**17 - 1 and this is also the largest positive value representable by
your representation. If this is not the case for your implementation,
it is NOT using a *pure binary representation* and, therefore, it is
non-conforming, period.
It is not by pure accident that all the limits for the type_MAX macros
in <limits.h> are one less than a power of two.
Dan
Sheldon Simms
What you are saying is true for unsigned integer types:
6.2.6.2#1
If there are N value bits, each bit shall represent a different power
of 2 between 1 and 2N-1, so that objects of that type shall be capable of
representing values from 0 to 2N - 1 using a pure binary representation;
However, the above does not apply to signed integer types. The only
requirement for signed integer types is
6.2.6.2#3
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
Furthermore the definition of pure binary notation in footnote 40
says nothing about the maximum and minimum values represented by
any integer type. It only defines the values of individual bits and
specifies that their values are additive. My representation meets
those requirements and is therefore a pure binary representation.
The definitions in the standard declare unambiguously that the
implementation I have presented is conforming. There is no need to
appeal to "arbitrary exceptions". The standard places no requirement
on the range of values represented by signed integer types apart from
those in 5.2.4.2.1.
> It is not by pure accident that all the limits for the type_MAX macros
> in <limits.h> are one less than a power of two.
That is irrelevant. No requirement is placed on the interpretation of
the object representation of integers by those limits, apart from the
necessity of representing values that meet or exceed those limits.
-Sheldon
Sheldon Simms
> In <3FB94F88...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>
>>Everything you've said is something I said to him the last time we went
>>through this, with different wording. I doubt it will change his mind.
>
> It would take a lot more than two people who can't read a definition to
> change my mind.
>
>>There's something in his way of reading those sentences that causes him
>>to see more restrictions than you or I do.
>
> The definition of pure binary representation is crystal clear and there
> is no way to introduce exceptions into it by quoting 6.2.6.1, a more
> generic paragraph.
The definition of pure binary representation says nothing about whether
any bit pattern is a trap representation. It specifies only 1) the value
of each bit and 2) that the values are additive.
5.2.4.2.1 then specifies the range of values that must be representable
by integer types.
Reading the definitions is the easy part. The difficult part is figuring
out why you insist on reading requirements that aren't there.
Dan Pop
>On Tue, 18 Nov 2003 11:49:12 +0000, Dan Pop wrote:
>
>> In <3FB94F88...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>
>>>Everything you've said is something I said to him the last time we went
>>>through this, with different wording. I doubt it will change his mind.
>>
>> It would take a lot more than two people who can't read a definition to
>> change my mind.
>>
>>>There's something in his way of reading those sentences that causes him
>>>to see more restrictions than you or I do.
>>
>> The definition of pure binary representation is crystal clear and there
>> is no way to introduce exceptions into it by quoting 6.2.6.1, a more
>> generic paragraph.
>
>The definition of pure binary representation says nothing about whether
>any bit pattern is a trap representation.
Therefore, no value bit pattern can be a trap representation. It's as
simple as that.
>It specifies only 1) the value
>of each bit and 2) that the values are additive.
Which is enough for *uniquely* specifying the value associated with every
value bit pattern. Without leaving place for any exception. That's why
it's called *pure* binary representation.
The only trap representations (involving only sign and value bits)
specified by 6.2.6.2 have the sign bit set, so they are not entirely
covered by footnote 40.
>5.2.4.2.1 then specifies the range of values that must be representable
>by integer types.
>
>Reading the definitions is the easy part. The difficult part is figuring
>out why you insist on reading requirements that aren't there.
It might be easy to read the definitions, if you don't have to also
understand them. Once you manage to understand them, you'll see that
the requirements are there: the definition doesn't exclude *any* value bit
pattern, therefore neither can a conforming implementation.
Dan Pop
It is enough. Apply it to 0--- ---- ---- ---1 1111 1111 1111 1111 and
see what you get.
>Furthermore the definition of pure binary notation in footnote 40
>says nothing about the maximum and minimum values represented by
>any integer type.
It doesn't have to. When the sign bit is zero, the maximum value follows
from the definition. For those who can read it, at least.
When the sign bit is set, there is explicit wording in 6.2.6.2 about what
the allowed behaviours are. The minimum value follows from footnote 40
combined with that wording. For those who can perform this exercise,
at least.
>It only defines the values of individual bits and
>specifies that their values are additive. My representation meets
>those requirements and is therefore a pure binary representation.
If it meets those requirements, then what is the value of
0--- ---- ---- ---1 1111 1111 1111 1111?
CBFalconer
> Sheldon Simms <sheldo...@yahoo.com> writes:
>
... snip ...
>
> When the sign bit is set, there is explicit wording in 6.2.6.2
> about what the allowed behaviours are. The minimum value follows
> from footnote 40 combined with that wording. For those who can
> perform this exercise, at least.
>
> > It only defines the values of individual bits and specifies
> > that their values are additive. My representation meets those
> > requirements and is therefore a pure binary representation.
>
> If it meets those requirements, then what is the value of
> 0--- ---- ---- ---1 1111 1111 1111 1111?
While it would be quite convenient to agree with Mr. Simms, the
following underlined wording in N869 seems to preclude it.
6.2.6.2 Integer types
[#1] For unsigned integer types other than unsigned char,
the bits of the object representation shall be divided into
two groups: value bits and padding bits (there need not be
any of the latter). If there are N value bits, each bit
shall represent a different power of 2 between 1 and 2N-1,
so that objects of that type shall be capable of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
representing values from 0 to 2N-1 using a pure binary
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
representation; this shall be known as the value
^^^^^^^^^^^^^^
representation. The values of any padding bits are
unspecified.39)
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
James Kuyper
What you snipped included a quotation of the following, very relevant
text written by Sheldon Simms:
>What you are saying is true for unsigned integer types:
>
> 6.2.6.2#1
> If there are N value bits, each bit shall represent a different power
> of 2 between 1 and 2N-1, so that objects of that type shall be capable of
> representing values from 0 to 2N - 1 using a pure binary representation;
>
>However, the above does not apply to signed integer types. The only
>requirement for signed integer types is
[returning to your message]
...
> > > It only defines the values of individual bits and specifies
> > > that their values are additive. My representation meets those
> > > requirements and is therefore a pure binary representation.
> >
> > If it meets those requirements, then what is the value of
> > 0--- ---- ---- ---1 1111 1111 1111 1111?
>
> While it would be quite convenient to agree with Mr. Simms, the
> following underlined wording in N869 seems to preclude it.
>
> 6.2.6.2 Integer types
>
> [#1] For unsigned integer types other than unsigned char,
^^^^^^^^
> the bits of the object representation shall be divided into
> two groups: value bits and padding bits (there need not be
> any of the latter). If there are N value bits, each bit
> shall represent a different power of 2 between 1 and 2N-1,
> so that objects of that type shall be capable of
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> representing values from 0 to 2N-1 using a pure binary
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> representation; this shall be known as the value
> ^^^^^^^^^^^^^^
> representation. The values of any padding bits are
> unspecified.39)
Sheldon has already acknowledged the applicability of this clause to
unsigned types. His very explicitly restricted his statements as
applying only to signed types.
If anything, the existence of this explicit requirement for unsigned
integers is an argument against the same requirement applying to signed
integers. Why would they bother stating the requirement ONLY for
unsigned integers, if a comparable requirement was intended to also
apply for signed types? Why bother stating it if it should be inferred
from the description of the bit values?
Granted; the statement of the requirement would have had to be more
complicated for the signed types, since the range would have to be
different for each of three allowed ways of interpreting the sign bit.
However, I doubt that was the reason for ommitting such wording.
Actually, the fact that the description would be more complicated is all
the more reason for including it; the more complicated it is, the more
important it is to make sure it's explicitly stated, to reduce the
liklihood of people getting it wrong.
Dan Pop
And the paragraph dealing with signed types says:
2 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.
According to the posted quotes, what is the value associated to the
representation in question: 0--- ---- ---- ---1 1111 1111 1111 1111 ?
Sheldon Simms
> In <pan.2003.11.18....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>
>>What you are saying is true for unsigned integer types:
>>
>> 6.2.6.2#1
>> If there are N value bits, each bit shall represent a different power
>> of 2 between 1 and 2N-1, so that objects of that type shall be capable of
>> representing values from 0 to 2N - 1 using a pure binary representation;
>>
>>However, the above does not apply to signed integer types. The only
>>requirement for signed integer types is
>>
>> 6.2.6.2#2
>> 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
>
> It is enough. Apply it to 0--- ---- ---- ---1 1111 1111 1111 1111 and
> see what you get.
That is a trap representation, by definition.
The standard clearly states that each BIT shall have the same value,
this is true of my representation, as previously demonstrated. The
standard does not require that every pattern of value bits in the
object representation of signed integer types represent a valid value.
In fact, the standard explicitly admits the possibility that some
object representations are not valid values:
6.2.6.1#5
Certain object representations need not represent a value of the
object type.
You are farcically attempting to claim that the standard's guarantee
about the values of individual bits is in fact a guarantee about the
value of the entire object. That inference is not supported by the
text, which quite clearly is talking about the values of bits.
>>Furthermore the definition of pure binary notation in footnote 40
>>says nothing about the maximum and minimum values represented by
>>any integer type.
>
> It doesn't have to. When the sign bit is zero, the maximum value follows
> from the definition. For those who can read it, at least.
The definition says only that the values of successive bits are
additive. This defines how we construct values from value bits
when we wish to do so, but it does not define which patterns of
value bits are valid in the first place.
> When the sign bit is set, there is explicit wording in 6.2.6.2 about what
> the allowed behaviours are.
Which my representation implements completely, as previously demonstrated.
-Sheldon
Sheldon Simms
> In <pan.2003.11.18....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>
>>On Tue, 18 Nov 2003 11:49:12 +0000, Dan Pop wrote:
>>
>>> In <3FB94F88...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>>
>>>>Everything you've said is something I said to him the last time we went
>>>>through this, with different wording. I doubt it will change his mind.
>>>
>>> It would take a lot more than two people who can't read a definition to
>>> change my mind.
>>>
>>>>There's something in his way of reading those sentences that causes him
>>>>to see more restrictions than you or I do.
>>>
>>> The definition of pure binary representation is crystal clear and there
>>> is no way to introduce exceptions into it by quoting 6.2.6.1, a more
>>> generic paragraph.
>>
>>The definition of pure binary representation says nothing about whether
>>any bit pattern is a trap representation.
>
> Therefore, no value bit pattern can be a trap representation. It's as
> simple as that.
Nonsense. The definition of pure binary representation specifies what
the values of successive bits are and specifies that their values are
additive. It does not require that every pattern of value bits actually
represent a valid value.
>>It specifies only 1) the value
>>of each bit and 2) that the values are additive.
>
> Which is enough for *uniquely* specifying the value associated with every
> value bit pattern. Without leaving place for any exception. That's why
> it's called *pure* binary representation.
It is enough for uniquely specifying the value associated with each
value bit pattern *if* the value bit pattern is a valid value. The
definition does not require that every pattern of value bits be a
valid value.
> the definition doesn't exclude *any* value bit
> pattern, therefore neither can a conforming implementation.
The definition also doesn't *include* any value bit pattern. It describes
how to construct an value of the object type from bit values given an
object representation that actually represents a valid value of the object
type.
If the object representation does not represent a valid value, then trying
to compute its value using the definition of pure binary representation is
a meaningless exercise.
Dan Pop
>On Wed, 19 Nov 2003 09:38:22 +0000, Dan Pop wrote:
>
>> In <pan.2003.11.18....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>>
>>>On Tue, 18 Nov 2003 11:49:12 +0000, Dan Pop wrote:
>>>
>>>> In <3FB94F88...@saicmodis.com> James Kuyper <kuy...@saicmodis.com> writes:
>>>>
>>>>>Everything you've said is something I said to him the last time we went
>>>>>through this, with different wording. I doubt it will change his mind.
>>>>
>>>> It would take a lot more than two people who can't read a definition to
>>>> change my mind.
>>>>
>>>>>There's something in his way of reading those sentences that causes him
>>>>>to see more restrictions than you or I do.
>>>>
>>>> The definition of pure binary representation is crystal clear and there
>>>> is no way to introduce exceptions into it by quoting 6.2.6.1, a more
>>>> generic paragraph.
>>>
>>>The definition of pure binary representation says nothing about whether
>>>any bit pattern is a trap representation.
>>
>> Therefore, no value bit pattern can be a trap representation. It's as
>> simple as that.
>
>Nonsense. The definition of pure binary representation specifies what
>the values of successive bits are and specifies that their values are
>additive. It does not require that every pattern of value bits actually
>represent a valid value.
It does, by not allowing any exceptions. There is no way to introduce
arbitrary exceptions in a *definition*. Since you can't understand
something as simple as that, I'm over and out.
Dan Pop
>On Wed, 19 Nov 2003 09:27:15 +0000, Dan Pop wrote:
>
>> In <pan.2003.11.18....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>>
>>>What you are saying is true for unsigned integer types:
>>>
>>> 6.2.6.2#1
>>> If there are N value bits, each bit shall represent a different power
>>> of 2 between 1 and 2N-1, so that objects of that type shall be capable of
>>> representing values from 0 to 2N - 1 using a pure binary representation;
>>>
>>>However, the above does not apply to signed integer types. The only
>>>requirement for signed integer types is
>>>
>>> 6.2.6.2#2
>>> 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
>>
>> It is enough. Apply it to 0--- ---- ---- ---1 1111 1111 1111 1111 and
>> see what you get.
>
>That is a trap representation, by definition.
By whose definition? If it's a trap representation, how can each of its
bits have the same value as in the case of the unsigned int type?
>The standard clearly states that each BIT shall have the same value,
>this is true of my representation, as previously demonstrated. The
>standard does not require that every pattern of value bits in the
>object representation of signed integer types represent a valid value.
It does, by requiring that each BIT shall have the same value.
>In fact, the standard explicitly admits the possibility that some
>object representations are not valid values:
>
> 6.2.6.1#5
> Certain object representations need not represent a value of the
> object type.
I have explained N times that 6.2.6.1 cannot override the specifications
provided by a more specific paragraph.
>You are farcically attempting to claim that the standard's guarantee
>about the values of individual bits is in fact a guarantee about the
>value of the entire object. That inference is not supported by the
>text, which quite clearly is talking about the values of bits.
The standard also provides the connexion between the value of each bit
and the value of the bit pattern. You're using it yourself, in your
examples.
But if you want to stick to your silly position about individual bits,
what is the value associated to the following representation:
0--- ---- ---- ---1 0000 0000 0000 0000 ?
Now, we're talking anout a single value bit, that must have the same value
in both signed and unsigned int, right?
Sheldon Simms
> In <pan.2003.11.19....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>
>>On Wed, 19 Nov 2003 09:27:15 +0000, Dan Pop wrote:
>>
>>> In <pan.2003.11.18....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>>>
>>>>What you are saying is true for unsigned integer types:
>>>>
>>>> 6.2.6.2#1
>>>> If there are N value bits, each bit shall represent a different power
>>>> of 2 between 1 and 2N-1, so that objects of that type shall be capable of
>>>> representing values from 0 to 2N - 1 using a pure binary representation;
>>>>
>>>>However, the above does not apply to signed integer types. The only
>>>>requirement for signed integer types is
>>>>
>>>> 6.2.6.2#2
>>>> 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
>>>
>>> It is enough. Apply it to 0--- ---- ---- ---1 1111 1111 1111 1111 and
>>> see what you get.
>>
>>That is a trap representation, by definition.
>
> By whose definition?
By arbitrary, but conforming, decision of the implementation.
> If it's a trap representation, how can each of its
> bits have the same value as in the case of the unsigned int type?
Easily. A value bit's value depends on its position. Value bits in the
object representation of a signed integer type have the same value as
the bit in the same position in the corresponding unsigned type.
Obviously it is meaningless to talk about the value of a bit, or
even to consider a particular bit to be a value bit, if that
bit never contributes its positional value to the value of some
representable integer.
On the other hand, if a bit does contribute its positional value to
the value of some representable integer, then it clearly must be
a value bit. However, there is no requirement in the standard that
*every* object representation in which a particular value bit is
set must be a valid value of the object type.
In this representation, the 17th bit from the right has the value
2**(N-1) == 2**16 == 65536, as required by the standard. This bit
never contributes its positional value to the value of a positive
integer since every object representation in which the sign bit is
zero and the 17th bit from the left is one is a trap representation.
Nonetheless, it is clear that the 17th bit from the right does
have the value 65536 and is a value bit because it is necessary
for the representation of valid negative values. This is demonstrated
by the representation of the value -49152, which is:
1--- ---- ---- ---1 0100 0000 0000 0000
The value of the set value bits is (from right to left)
16384, 65536. The value of the sign bit is (as required by the
standard) -131072. The sum of the values of these bits is
16384+65536-131072 == -49152.
>>The standard clearly states that each BIT shall have the same value,
>>this is true of my representation, as previously demonstrated. The
>>standard does not require that every pattern of value bits in the
>>object representation of signed integer types represent a valid value.
>
> It does, by requiring that each BIT shall have the same value.
See above.
>>In fact, the standard explicitly admits the possibility that some
>>object representations are not valid values:
>>
>> 6.2.6.1#5
>> Certain object representations need not represent a value of the
>> object type.
>
> I have explained N times that 6.2.6.1 cannot override the specifications
> provided by a more specific paragraph.
The "specifications" you are talking about only exist in your imagination.
>>You are farcically attempting to claim that the standard's guarantee
>>about the values of individual bits is in fact a guarantee about the
>>value of the entire object. That inference is not supported by the
>>text, which quite clearly is talking about the values of bits.
>
> The standard also provides the connexion between the value of each bit
> and the value of the bit pattern. You're using it yourself, in your
> examples.
It does, but it does not require that every such combination of value
bits be a valid value.
> But if you want to stick to your silly position about individual bits,
> what is the value associated to the following representation:
>
> 0--- ---- ---- ---1 0000 0000 0000 0000 ?
Trap representation
> Now, we're talking anout a single value bit, that must have the same value
> in both signed and unsigned int, right?
The bit has the same value, as shown above. But the object representation
isn't a valid value.
-Sheldon
Sheldon Simms
It's not a matter of allowing exceptions, whether arbitrary or not. The
definition simply does not say anything at all about whether a particular
combination of bits is a valid value or a trap representation.
In the representation I have presented, every valid positive value is
determined by the sum of the positional values of set value bits exactly
as specified in footnote 40. That makes it a pure binary notation. The
fact that some patterns of bits are trap representations rather than valid
values is not only nowhere prohibited by the standard, it is explicitly
allowed by the standard.
-Sheldon
Dan Pop
This is sheer insanity. No point in continuing this discussion.
Sheldon Simms
> In <pan.2003.11.20....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>
>>On Thu, 20 Nov 2003 11:35:42 +0000, Dan Pop wrote:
>>
>>> But if you want to stick to your silly position about individual bits,
>>> what is the value associated to the following representation:
>>>
>>> 0--- ---- ---- ---1 0000 0000 0000 0000 ?
>>
>>Trap representation
>>
>>> Now, we're talking anout a single value bit, that must have the same value
>>> in both signed and unsigned int, right?
>>
>>The bit has the same value, as shown above. But the object representation
>>isn't a valid value.
>
> This is sheer insanity.
No it isn't. It simply doesn't fit in with your preconceived notions
of how things ought to work. It is perfectly consistent with the text
of the standard.
> No point in continuing this discussion.
Guess the result is clear then. You were wrong.
Dan Pop
The definition assigns a value to *any* combination of value bits, leaving
no place for exceptions.
Sheldon Simms
Wrong. The definition describes how to assign a value to any combination
of value bits. It does not specify that a value must be assigned to every
combination of value bits.
Dan Pop
It does, implicitly, by not leaving room for exceptions.
Wojtek Lerch
By this reasoning, the only trap representations an integer type can
possibly have are the ones that 6.2.6.2p2 specifically describes
("negative zeros"), and footnote 44 is bogus. Are you claiming that,
too?
Sheldon Simms
Are you just acting stupid?
Describing how to do something is not the same as requiring that it must
be done. Footnote 40 places no requirement on the range of values
representable by integer types.
Your whole obsession with "exceptions" of footnote 40 shows that you can't
(or don't want to) understand plain English. While that isn't a fault in
general, it is certainly a defect when trying to understand the C standard.
Dan Pop
>Dan...@cern.ch (Dan Pop) wrote in message news:<bpkps3$8ri$2...@sunnews.cern.ch>...
>> In <pan.2003.11.20....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>> >Wrong. The definition describes how to assign a value to any combination
>> >of value bits. It does not specify that a value must be assigned to every
^^^^^
>> >combination of value bits.
>> ^^^^^
>> It does, implicitly, by not leaving room for exceptions.
>
>By this reasoning, the only trap representations an integer type can
>possibly have are the ones that 6.2.6.2p2 specifically describes
>("negative zeros"), and footnote 44 is bogus. Are you claiming that,
>too?
Your logic is faulty. The definition in question does NOT address
padding bits at all and, therefore, is not applicable to them.
The whole discussion was focused *exclusively* on value bits, as
explicitly stated all over the place.
Dan Pop
OK, you have provided the ultimate proof that you have no clue about what
a definition is. Free clue: it's not a recipe.
Christian Bau
wrote:
> It does, implicitly, by not leaving room for exceptions.
Assume for example that int has 40 bits in its representation, and 31
value + 1 sign bit.
For each of the 2^32 possible combinations of value + sign bit, there
are 256 possible combinations of padding bits. I think everyone agrees
that out of those 256 possible combinations, up to 255 could produce a
trap representation. I think everyone also agrees that if you look only
at the value bits, you can determine the one possible legal value that a
representation could have if it is not a trap representation.
The question is: Could it be possible for certain value+sign bit
combinations that all 256 possible combinations of the padding bits
produce a trap representation?
Wojtek Lerch
> In <ca7e6477.03112...@posting.google.com> Wojt...@yahoo.ca (Wojtek Lerch) writes:
>>Dan...@cern.ch (Dan Pop) wrote in message news:<bpkps3$8ri$2...@sunnews.cern.ch>...
>>
>>>In <pan.2003.11.20....@yahoo.com> Sheldon Simms <sheldo...@yahoo.com> writes:
>>>
>>>>Wrong. The definition describes how to assign a value to any combination
>>>>of value bits. It does not specify that a value must be assigned to every
> ^^^^^
>>>>combination of value bits.
>>> ^^^^^
>>>It does, implicitly, by not leaving room for exceptions.
>>>
>>By this reasoning, the only trap representations an integer type can
>>possibly have are the ones that 6.2.6.2p2 specifically describes
>>("negative zeros"), and footnote 44 is bogus. Are you claiming that,
>>too?
>
> Your logic is faulty. The definition in question does NOT address
> padding bits at all and, therefore, is not applicable to them.
Of course not. The definition is just a quotation from an English
dictionary, cited in a footnote of the C standard. I wouldn't be
surprised if that dictionary didn't even define "padding bits".
After a closer look, I don't even think that definition is very relevant
to a discussion of whether INT_MAX must be one less than a power of two.
The standard never says that signed integers use a pure binary
representation. It just explains how certain bits and bit patterns in
representations of signed integers must be related to representations of
unsigned integers. That has no relevance to saying what values *must*
be representable.
> The whole discussion was focused *exclusively* on value bits, as
> explicitly stated all over the place.
I know; and my point is that it's a mistake to ignore padding bits in a
discussion about whether the standard allows certain combinations of
bits to be trap representations or not.
Sheldon Simms
The definition in footnote 40 exists independent of the C language.
It defines pure binary notation by describing what a value representation
must be to be considered pure binary notation. The definition says that
pure binary notation is:
- A positional representation. In a pure binary notation, a collection
of bits is ordered, and each bit has a value determined by its
position relative to other bits. In particular, the value of each
bit is its value multiplied by 2**N, where N is its position in
the collection, starting at N == 0 for the least bit.
- An additive representation. A collection of bits can be considered
to have a value that is determined by adding the values of the
individual bits in the collection.
This definition places no requirement on C implementations whatsoever.
The standard text itself places requirements on C implementations. One of
these requirements is that unsigned integer types must be represented
using a pure binary notation. This means, for example, that no conforming
implementation could both represent 2 as 0010 and 3 as 1001, regardless of
whether these representations were unique to their value or not.
The standard text also allows "certain object representations" to "not
represent a value of the object type". There is no conflict between this
requirement and the requirement that unsigned integer types be represented
using a pure binary notation. If an implementation defines a particular
bit pattern to be a trap representation, then it has no value at all.
Your question about the value of 0--- ---- ---- ---1 0000 0000 0000 0000
was meaningless because a trap representation doesn't have a value.
You are asserting that my representation doesn't conform because it
isn't a pure binary representation. However, every integer value
is represented exactly as described in the definition of pure binary
notation. It is just that some bit patterns that you think *should* be
values, are not values. This *should* is mentioned nowhere in the text.
It is a fantasy of yours.
cody
The values of the padding bits are always undefined. Every combination of
them could be a trap representation as well as None. That means you can only
be sure that the number of trap representations in 8 padding bits lies
between 0 and 255.
Additionally can a certain combination of value, sign and padding bits
produce a trap representation because padding bits could internally be
parity bits/crc values.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Christian Bau
"cody" <dont.spam.m...@gmx.de> wrote:
> > > It does, implicitly, by not leaving room for exceptions.
> >
> > Assume for example that int has 40 bits in its representation, and 31
> > value + 1 sign bit.
> >
> > For each of the 2^32 possible combinations of value + sign bit, there
> > are 256 possible combinations of padding bits. I think everyone agrees
> > that out of those 256 possible combinations, up to 255 could produce a
> > trap representation. I think everyone also agrees that if you look only
> > at the value bits, you can determine the one possible legal value that a
> > representation could have if it is not a trap representation.
> >
> > The question is: Could it be possible for certain value+sign bit
> > combinations that all 256 possible combinations of the padding bits
> > produce a trap representation?
>
> The values of the padding bits are always undefined. Every combination of
> them could be a trap representation as well as None. That means you can only
> be sure that the number of trap representations in 8 padding bits lies
> between 0 and 255.
Now tell us how you conclude that the number of trap representations
lies between 0 and 255. First, you surely mean "from 0 to 255
inclusive". "Between 0 and 255" means at least 1, at most 254. Second,
why not 256?
cody
news:christian.bau-C7E...@slb-newsm1.svr.pol.co.uk...
Yes I meant from 0 to 255 inclusive. I should better have said 0 to 255 trap
representations for each value (value=all value bits+sign bit).
When there would be 256 trap representations for 8 padding bits then there
would be no valid value at all.
The values of the padding bits are defined as undefined by the standard and
modification of them can lead to trap representations. That means you cannot
know which combination of padding bits with value bits and sign bit is a
trap representation.
Christian Bau
"cody" <dont.spam.m...@gmx.de> wrote:
> Yes I meant from 0 to 255 inclusive. I should better have said 0 to 255 trap
> representations for each value (value=all value bits+sign bit).
> When there would be 256 trap representations for 8 padding bits then there
> would be no valid value at all.
For heavens sake, THAT was what this discussion is about! Some people
here claim that some values might not have a valid representation
because _each_ combination of padding bits could be a trap
representation, and then you say no, not every combination must be a
trap representation because then some values would not have a valid
representation.
cody
As I already said, the padding bits are always undefined and a discussion
how many valid representations under which circumstances there are is
pointless.
Fact is: For each *valid* *value* there must be at least one valid
combination of padding bits.
The question know is: how many invalid *values* can there be? imho only
signed integral types can have trap representations, and only values with
the sign bit set.
I think Dan Pop was right: Negative Zero(-0) or -(MAXVALUE+1) or both can be
trap representations, depending on the platform.
Christian Bau
"cody" <dont.spam.m...@gmx.de> wrote:
> "Christian Bau" <christ...@cbau.freeserve.co.uk> schrieb im Newsbeitrag
> news:christian.bau-9A9...@slb-newsm1.svr.pol.co.uk...
> > In article <bpq858$1qil8m$1...@ID-176797.news.uni-berlin.de>,
> > "cody" <dont.spam.m...@gmx.de> wrote:
> >
> > > Yes I meant from 0 to 255 inclusive. I should better have said 0 to 255
> trap
> > > representations for each value (value=all value bits+sign bit).
> > > When there would be 256 trap representations for 8 padding bits then
> there
> > > would be no valid value at all.
> >
> > For heavens sake, THAT was what this discussion is about! Some people
> > here claim that some values might not have a valid representation
> > because _each_ combination of padding bits could be a trap
> > representation, and then you say no, not every combination must be a
> > trap representation because then some values would not have a valid
> > representation.
>
> As I already said, the padding bits are always undefined and a discussion
> how many valid representations under which circumstances there are is
> pointless.
> Fact is: For each *valid* *value* there must be at least one valid
> combination of padding bits.
Read the posts on this thread. What you claim is fact is exactly what is
debated. Except that you manage again to muddle things: By definition,
valid values can be stored in a representation that is not a trap
representation. However, not every combination of value bits is
guaranteed to be valid - at least that is what this thread is about.
cody
255
> > trap
> > > > representations for each value (value=all value bits+sign bit).
> > > > When there would be 256 trap representations for 8 padding bits then
> > there
> > > > would be no valid value at all.
> > >
> > > For heavens sake, THAT was what this discussion is about! Some people
> > > here claim that some values might not have a valid representation
> > > because _each_ combination of padding bits could be a trap
> > > representation, and then you say no, not every combination must be a
> > > trap representation because then some values would not have a valid
> > > representation.
> >
> > As I already said, the padding bits are always undefined and a
discussion
> > how many valid representations under which circumstances there are is
> > pointless.
> > Fact is: For each *valid* *value* there must be at least one valid
> > combination of padding bits.
>
> Read the posts on this thread. What you claim is fact is exactly what is
> debated. Except that you manage again to muddle things: By definition,
> valid values can be stored in a representation that is not a trap
> representation.
That is exactly what I said with the last quoted sentence!
> However, not every combination of value bits is
> guaranteed to be valid - at least that is what this thread is about.
I never questioned that.
Christian Bau
"cody" <dont.spam.m...@gmx.de> wrote:
I conclude that you didn't understand a thing.
Dan Pop
>Dan Pop wrote:
>
>> The whole discussion was focused *exclusively* on value bits, as
>> explicitly stated all over the place.
>
>I know; and my point is that it's a mistake to ignore padding bits in a
>discussion about whether the standard allows certain combinations of
>bits to be trap representations or not.
It wasn't a mistake, it was a deliberate choice, because padding bits
are entirely irrelevant to the core of the debate: is the implementation
free to choose arbitrary values for the signedtype_MAX macros, as long as
they exceed the minimum values required by the standard?
Dan Pop
Yes, of course, if the trap representation is not generated by them ;-)
The standard explicitly provides one value+sign bit combination for each
of the three supported representations that can be defined as a trap
representation by a conforming implementation.
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.
Wojtek Lerch
They are relevant to the argument you were making: you seemed to claim
that only a representation where the value and sign bits match the
description of "negative zero" is allowed to be a trap representation.
If we assume that that claim is correct, talking about padding bits is
indeed irrelevant to the original subject. But if we look at your
claim without ignoring the existence of padding bits, we might notice
that your claim makes less sense than it seemed to before we thought
about pading bits. Is that perhaps why you refuse talking about
padding bits? :-)
cody
I don't see where your problem lies. If I failed to correctly express my
words in english please say it.
Dan Pop
>Dan...@cern.ch (Dan Pop) wrote in message news:<bpt1m8$s7m$5...@sunnews.cern.ch>...
>> In <3FBEC1C7...@yahoo.ca> Wojtek Lerch <Wojt...@yahoo.ca> writes:
>> >Dan Pop wrote:
>> >> The whole discussion was focused *exclusively* on value bits, as
>> >> explicitly stated all over the place.
>> >
>> >I know; and my point is that it's a mistake to ignore padding bits in a
>> >discussion about whether the standard allows certain combinations of
>> >bits to be trap representations or not.
>>
>> It wasn't a mistake, it was a deliberate choice, because padding bits
>> are entirely irrelevant to the core of the debate: is the implementation
>> free to choose arbitrary values for the signedtype_MAX macros, as long as
>> they exceed the minimum values required by the standard?
>
>They are relevant to the argument you were making: you seemed to claim
>that only a representation where the value and sign bits match the
>description of "negative zero" is allowed to be a trap representation.
I've never claimed that. I even explained that that was your broken
interpretation of my statements.
The meaning of an integer object representation is determined both
by the value (and sign) bits and the padding bits. But, for reasons
already explained we decided to ignore the effect of the padding bits
in the discussion.
Don't you have anything better to do than beating this dead horse?