A
Ark Khasin
Ty. But Richard offered a satisfactory explanation.santosh said:This is most hilarious sentence I've read in c.l.c. this year.
Ty. But Richard offered a satisfactory explanation.santosh said:This is most hilarious sentence I've read in c.l.c. this year.
Ark said:Is this "just a theory"? IMHO, 6.2.6.2 says *exactly nothing* about
unsigned char.
Is this "just a theory"?
Thanks to adding to my confusionpete said:Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
Ark said:.... snip ...
As a practitioner, I didn't think twice to clear all bits with
memset clones including the likes of the code above. But now this
post scared me: if unsigned char has padding bits in its
representation (which I guess is allowed) then what do I get?
unsigned a;
memset_as_above(&a, 0, sizeof(a));
Will a necessarily compare equal to 0?
Ark said:Thanks to adding to my confusionpete said:Ark said:santosh wrote:
Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>
No. unsigned char may not have padding bits.Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
So I have an 11-bit machine bytes and UCHAR_MAX==8 and 3 padding most
significant bits. Anything wrong?
BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.
pete said:[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
Thanks to adding to my confusion
So I have an 11-bit machine bytes and UCHAR_MAX==8 and 3 padding most
significant bits. Anything wrong?
BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.
... my understanding was in pointer context 0 and NULL is converted to
null pointer.
And converting to null pointer is compiler responsibility.
So I thought 0 in memset will be converted to null
pointer (which is system specific).
Thanks to adding to my confusionpete said:Ark said:santosh wrote:
Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>
No. unsigned char may not have padding bits.Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1 shall equal 2 raised to the
power CHAR_BIT.
So I have an 11-bit machine bytes and UCHAR_MAX==8 and 3 padding most
significant bits. Anything wrong?
BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.
That's where I am lost and reading the standard doesn't help:
What's the difference between a value of an object and how it compares
equal? I mean, if a==b, whatever their representations, in what
context(s) does it make sense to say they may have different values?
[NEGATIVE_ZERO comes to mind - and goes away. BTW, is it fair to say
that bitwise logic is a magic performed on representations, and not on
values?]
//Which is correct but implies
{
void **pNULL = 0;
if(a==*pNULL) {
/* not guaranteed */
Ark said:Thanks to adding to my confusionArk said:santosh wrote:
Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>
No. unsigned char may not have padding bits.Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
So I have an 11-bit machine bytes
James Kuyper said:[>> Ben Bacarisse wrote:]
...
The parenthesized comment was not actually needed to make the
statement "scrupulously correct"; it would have been just as correct,
and less confusing, without it.
[NEGATIVE_ZERO comes to mind - and goes away. BTW, is it fair to say
that bitwise logic is a magic performed on representations, and not
on values?]
No. In general, the bitwise operations are defined in terms of their
actions on the values, not the representations.
Sorry for being that stubborn, but:pete said:Thanks to adding to my confusion<snip>
No. unsigned char may not have padding bits.
Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
So I have an 11-bit machine bytes
That's what "CHAR_BIT equals eleven" means.
Yes, I took a beating in this ng recently for proposing, as an academicBen said:No. In general, the bitwise operations are defined in terms of their[NEGATIVE_ZERO comes to mind - and goes away. BTW, is it fair to say
that bitwise logic is a magic performed on representations, and not
on values?]
actions on the values, not the representations.
Is that true for &, |, ^ and ~? The definitions are very bland, but
they suggest (simply by saying so little) that the interpretation is
to be based on the representation. This is backed up by section
6.5p4.
Ark said:Sorry for being that stubborn, but:pete said:<snip>
No. unsigned char may not have padding bits.
Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
Thanks to adding to my confusion
So I have an 11-bit machine bytes
That's what "CHAR_BIT equals eleven" means.
Why?
Why can't I have CHAR_BIT==8 on a 11-bit machine?
E.g. my int would be something like say 11(lower)+8(upper)=19 bits.
Ark Khasin said:Why can't I have CHAR_BIT==8 on a 11-bit machine?
E.g. my int would be something like say 11(lower)+8(upper)=19 bits.
Sorry for posting nonsense contradicting 6.2.6.1 #4.Ark said:Sorry for being that stubborn, but:pete said:<snip>
No. unsigned char may not have padding bits.
Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
Thanks to adding to my confusion
So I have an 11-bit machine bytes
That's what "CHAR_BIT equals eleven" means.
Why?
Why can't I have CHAR_BIT==8 on a 11-bit machine?
E.g. my int would be something like say 11(lower)+8(upper)=19 bits.
Is it postulated somewhere that
UINT_MAX+1==(UCHAR_MAX+1)*sizeof(unsigned)
?
I don't think so.
Ark Khasin said:Yes, I took a beating in this ng recently for proposing, as anBen said:[NEGATIVE_ZERO comes to mind - and goes away. BTW, is it fair to say
that bitwise logic is a magic performed on representations, and not
on values?]
No. In general, the bitwise operations are defined in terms of their
actions on the values, not the representations.
Is that true for &, |, ^ and ~? The definitions are very bland, but
they suggest (simply by saying so little) that the interpretation is
to be based on the representation. This is backed up by section
6.5p4.
academic exercise,
int cmpneq(int a, int b){ return a^b; }
At the time, I agreed that the beating was well deserved. But as far
as I can tell, it depended on ^ operating on representations.
An authoritative and well-substantiated clarification would be more
than welcome!
Ark Khasin said:It appears indeed that I cannot have 11+9-bit int. While I can have
8+8=16-bit int etc, such a C machine would simply ignore the 3 of 11
bits. Or it can use for padding, which demonstrates that padding of
unsigned char is possible e.g. for trap values (for instance,
uninitialized or truncated on assignment or whatever).
Would it be a legit implementation?
Ark Khasin said:Sorry for posting nonsense contradicting 6.2.6.1 #4.Ark said:Sorry for being that stubborn, but:pete said:<snip>
No. unsigned char may not have padding bits.
Is this "just a theory"?
No.
N869
5.2.4.2.1 Sizes of integer types <limits.h>
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.
Thanks to adding to my confusion
So I have an 11-bit machine bytes
That's what "CHAR_BIT equals eleven" means.
Why?
Why can't I have CHAR_BIT==8 on a 11-bit machine?
E.g. my int would be something like say 11(lower)+8(upper)=19 bits.
Is it postulated somewhere that
UINT_MAX+1==(UCHAR_MAX+1)*sizeof(unsigned)
?
I don't think so.
It appears indeed that I cannot have 11+9-bit int. While I can have
8+8=16-bit int etc, such a C machine would simply ignore the 3 of 11
bits. Or it can use for padding, which demonstrates that padding of
unsigned char is possible e.g. for trap values (for instance,
uninitialized or truncated on assignment or whatever).
Would it be a legit implementation?
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.