Assigning values to char arrays

A

Ark Khasin

Ben said:
Ark Khasin said:
Ben said:
<snip>
[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.
Yes, I took a beating in this ng recently for proposing, as an
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!

If you think about it, you can *always* define the meaning in terms of
values even if it is more natural to think of it in terms of
representations. However, that would be stretching a point. An
expression like '-1 | -2' does not invoke undefined behaviour and the
result is most easily explained in terms of the representation of the
operands. (Of course it is daft, but that is not really the point.)
So, -1 | -2 (or better yet, (-1)^1) is... what? Does it not depend on
one of the 3 models of negatives C recognizes - 2's complement, 1's
complement and sign+magnitude?
 
A

Ark Khasin

James 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.
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?

There is no difference. Don't let the unnecessary "clarification"
confuse you. The issue isn't having different values with the same
representation in a single type - that can't happen. The issue is that
there can be multiple different representations of the same value in a
given type. However, the values of objects of that type containing those
different representations must compare equal.

You're tripping over a minor issue; the fact that there can be multiple
representations of a null pointer.
I don't think I am
However, you've lost track of the key
issue: that a pointer object with all of its bits set to 0 doesn't have
to be one of those representations. In fact, it doesn't have to
represent a valid pointer value of any kind.
I don't think I have. But I find it while correct, grotesque.
[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. For instance, E>>1 is
defined as dividing the value of E by 2.
No. E.g. with 2's complement machine and C99 (and perhaps 90% of C90)
a/2 is (a>=0)?(a>>1):((a+1)>>1)
The complicated exceptions all
involve sign bits, and most result in undefined behavior, which is why
it's strongly recommended that bitwise operations be restricted to
unsigned types, or at least restricted to values which are guaranteed to
be positive both before and after the operation.


There is, at this point, no guarantee that 'a' contains a valid pointer
representation.
Sure. But I find it while correct, grotesque.
Therefore, the next line renders the behavior of your
entire program undefined:


I'm not sure what your point was; but you've just attempted to
dereference a null pointer, again making the behavior undefined.
Oops.
I meant
void *pNULL = 0; //pNULL == NULL
a == pNULL not guaranteed.
Not that I don't grasp it; it just seems grotesque
 
B

Ben Bacarisse

So, -1 | -2 (or better yet, (-1)^1) is... what? Does it not depend on
one of the 3 models of negatives C recognizes - 2's complement, 1's
complement and sign+magnitude?

Yes. My reading of the standard is that whatever bits are set to
represent -1 and -2 (and that depends on the kind of negative number
system used) are OR'd to get the result.

1's comp s+mag 2's comp
-1 1..1111110 1..0000001 1..1111111
-2 1..1111101 1..0000010 1..1111110
-1 | -2 1..1111111 1..0000011 1..1111111
value -0 -3 -1

-1 1..1111110 1..0000001 1..1111111
1 0..0000001 0..0000001 0..0000001
-1 ^ 1 1..1111111 1..0000000 1..1111110
-0 -0 -2

I prefer my example since it can result in three values (or two values
and a trap representation).
 
J

James Kuyper

Ben said:
James Kuyper said:
Ark Khasin wrote: ....
[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

All of those operators work on values, not objects, and their meanings
are defined in terms of those values. The bits being referred to are
value bits. This is explicitly clear for the shift operators: for
unsigned types and for positive values of signed types, their behavior
is defined twice, once in terms of movement of bits, and a second time
in terms of multiplication or division by a power of 2. If they operated
on padding bits, then the definition of the right shift in terms of
division by a power of two would be incorrect; it would have to have
wording which allowed the high-order bits to acquire essentially random
contents.

It's less clear for the other bitwise operators, but I believe that
consistency with the shift operators requires that they also are defined
in terms of value and sign bits, and not the actual bits of the object.
Otherwise, how could they behave when operating on values that aren't
stored in any C object, like 'i+1'?
 
P

pete

Ark said:
So, -1 | -2 (or better yet, (-1)^1) is... what? Does it not depend on
one of the 3 models of negatives C recognizes - 2's complement, 1's
complement and sign+magnitude?

(-1 | -2) == {-1,-0,-3}
(-1 ^ 1) == {-2,-0,-0}


(-1) | (-2)
1111.1111 | 1111.1110 == (-1)
1111.1110 | 1111.1101 == (-0)
1000.0001 | 1000.0010 == (-3)


(-1) ^ (1)
1111.1111 ^ 0000.0001 == (-2)
1111.1110 ^ 0000.0001 == (-0)
1000.0001 ^ 0000.0001 == (-0)
 
B

Ben Bacarisse

Ark Khasin said:
James said:
Ark Khasin wrote:
[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. For instance, E>>1
is defined as dividing the value of E by 2.
No. E.g. with 2's complement machine and C99 (and perhaps 90% of C90)
a/2 is (a>=0)?(a>>1):((a+1)>>1)

That is rather unfair. James Kuyper goes on, immediately, to say that
the exceptions involve sign bits. He says that "most" of these cases
are undefined (which is correct) but you are also largely correct in
that shifting a signed and negative value one place left is
implementation defined (it is not connected to 2's compliment, it is
simply an implementation defined operation -- which may be undefined,
of course).
<snip>
 
J

James Kuyper

Ark said:
I don't think I have. But I find it while correct, grotesque.
....
No. E.g. with 2's complement machine and C99 (and perhaps 90% of C90)
a/2 is (a>=0)?(a>>1):((a+1)>>1)

As I said, the exceptions involve sign bits, and the behavior when the
sign bit is set is the key difference between what I wrote and what you
wrote. Please note that the behavior of (a+1)>>1 produces an
implementation-defined result when a+1 is negative; while the most
plausible behavior is to handle it in the fashion you expect, the
standard does not require it.
Sure. But I find it while correct, grotesque.

I can't help you with the aesthetic judgments. As a practical matter, I
believe that the standard lets these things depend upon the
implementation, precisely because there are real platforms where the
rules you'd like to see would make it unacceptably difficult to create
an efficient implementation of C. It wasn't just invented to make things
complicated for programmers.
Therefore, the next line renders the behavior of your
Oops.
I meant
void *pNULL = 0; //pNULL == NULL
a == pNULL not guaranteed.

With those changes, if it weren't for the fact that a had been filled in
by a call to memset that renders any use of 'a' dangerous, the rest of
this code would have been fine. If 'a' compared equal to 0, that would
normally have been sufficient to guarantee that it would also compare
equal to pNULL. All null pointers must compare equal, regardless of
representation, and no non-null pointer is allowed to compare equal to a
null pointer.
 
B

Ben Bacarisse

James Kuyper said:
Ben said:
James Kuyper said:
Ark Khasin wrote: ...
[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

All of those operators work on values, not objects, and their meanings
are defined in terms of those values. The bits being referred to are
value bits. This is explicitly clear for the shift operators: for
unsigned types and for positive values of signed types, their behavior
is defined twice, once in terms of movement of bits, and a second time
in terms of multiplication or division by a power of 2. If they
operated on padding bits, then the definition of the right shift in
terms of division by a power of two would be incorrect; it would have
to have wording which allowed the high-order bits to acquire
essentially random contents.

It's less clear for the other bitwise operators, but I believe that
consistency with the shift operators requires that they also are
defined in terms of value and sign bits, and not the actual bits of
the object. Otherwise, how could they behave when operating on values
that aren't stored in any C object, like 'i+1'?

I agree that consistency would suggest that the bits referred to in
the definitions of the other bitwise operators are value bits, but it
would have been so simple to state this (simpler, in fact, than in the
case of the shift operations where all sorts of special cases need to
be listed) that I am curious as to why it was not stated.

Even if we take it that only value bits are involved (and that seems
eminently reasonable) I still think it is simpler to explain the
meaning of '-1 | -2' in terms of the representation of the numbers.
It is simple to define 'x >> 1' in terms of the value of x (provided x
is positive) but this is not practical for the other bitwise
operators.

Of course '-1 | -2' takes two values and produces a third, and that
value can be explained entirely in terms of the values of the
operands, but to do so without describing the representation would be
very painful. I hope you don't think I am just playing with words.
Unless I am plain wrong in what I posted elsewhere about the possible
results of '-1 | -2', the operators like | depend on representations
in a way that the shift operators do not.
 
A

Ark Khasin

James said:
As I said, the exceptions involve sign bits, and the behavior when the
sign bit is set is the key difference between what I wrote and what you
wrote. Please note that the behavior of (a+1)>>1 produces an
implementation-defined result when a+1 is negative; while the most
plausible behavior is to handle it in the fashion you expect, the
standard does not require it.
I have to offer my apologies. It was unfair indeed to object to the
first 40% of the statement without parsing the meaning of the remaning 60%.
Sorry.
 
A

Ark Khasin

Ben said:
James Kuyper said:
Ben said:
Ark Khasin wrote: ...
[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
All of those operators work on values, not objects, and their meanings
are defined in terms of those values. The bits being referred to are
value bits. This is explicitly clear for the shift operators: for
unsigned types and for positive values of signed types, their behavior
is defined twice, once in terms of movement of bits, and a second time
in terms of multiplication or division by a power of 2. If they
operated on padding bits, then the definition of the right shift in
terms of division by a power of two would be incorrect; it would have
to have wording which allowed the high-order bits to acquire
essentially random contents.

It's less clear for the other bitwise operators, but I believe that
consistency with the shift operators requires that they also are
defined in terms of value and sign bits, and not the actual bits of
the object. Otherwise, how could they behave when operating on values
that aren't stored in any C object, like 'i+1'?

I agree that consistency would suggest that the bits referred to in
the definitions of the other bitwise operators are value bits, but it
would have been so simple to state this (simpler, in fact, than in the
case of the shift operations where all sorts of special cases need to
be listed) that I am curious as to why it was not stated.

Even if we take it that only value bits are involved (and that seems
eminently reasonable) I still think it is simpler to explain the
meaning of '-1 | -2' in terms of the representation of the numbers.
It is simple to define 'x >> 1' in terms of the value of x (provided x
is positive) but this is not practical for the other bitwise
operators.

Of course '-1 | -2' takes two values and produces a third, and that
value can be explained entirely in terms of the values of the
operands, but to do so without describing the representation would be
very painful. I hope you don't think I am just playing with words.
Unless I am plain wrong in what I posted elsewhere about the possible
results of '-1 | -2', the operators like | depend on representations
in a way that the shift operators do not.
Is it so that a consensus emerges that ^ | & on negative numbers depend
on representation (or, to tell the truth, act on representations) and so
are implementation-defined (although only 3 ways to implement are
recognized)?
 
J

Jean-Marc Bourguet

Chris Torek said:
Right. In practice, they tend to be clumped at one end (e.g., a
la Burroughs A-series machine where "integer" just means "floating
point value with carefully controlled exponent"). The most likely
candidate for "internal" padding bits would be a ones' complement
machine with no native at-least-32 and/or at-least-64 bit types,
where "long" and/or "long long" are made up of several machine
words glued together, with the sign bit unused (and always-0) in
the lower order words. One might do this when implementing C99 on
a Univac 11xx (Unisys? what *are* they called these days?) series
machine, for instance.

I seem to remember that the two's complement PDP-10 double length
instruction worked in that way: the sign bit was replicated in the two
words.

A very quick search seems to confirm, see the latest "news" here:
http://pdp10.nocrew.org/gcc/

Most notably, support for the long long type has been added. So far only
the "71-bit" double-precision integer format supported in hardware is
used, but in the future 72 bits of precision may be an option."


Yours,
 
P

pete

Ark 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.
Sorry for being that stubborn, but:
Why?

Because that's what "CHAR_BIT" means.

N869
5.2.4.2 Numerical limits
[#1]
-- number of bits for smallest object that is not a bit-
field (byte)
CHAR_BIT
 
J

James Kuyper

Ark Khasin wrote:
....
Is it so that a consensus emerges that ^ | & on negative numbers depend

I can't speak for the consensus; this is just my understanding of what
the standard says. In many cases my understanding differs distinctly
from the consensus understanding.
on representation (or, to tell the truth, act on representations) and so
are implementation-defined (although only 3 ways to implement are
recognized)?

Those operators don't act on the representations of objects; otherwise
cases like

x += (a+1) | (b-2);

would be undefined. The way that they operate on or generate negative
values must, however, be consistent with whichever of 3 permitted ways
of handling the sign bits that the implementation chose for the relevant
type. I see no way for those operators to operate on the padding bits
in any sense that is meaningful within the context of the standard. I
would expect that what happens is that the padding bits would be handled
just like the value bits, but that an implementation is not required to
do so. If you want to ensure that padding bits are handled in the same
fashion, you need to access the object as an array of unsigned char, and
perform the operations on a byte-by-byte basis.
 
S

somenath

pete said:
[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.

Ark Khasin said:
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?

Two.

First, I assume you meant for CHAR_BIT to be 8 here (so that
UCHAR_MAX is 255). :)

Second, if you have 11-bit machine bytes, CHAR_BIT must be 11
(or, alternatively, the implementation can make CHAR_BIT be 8
and completely hide the existence of the other 3 bits, by
emulating an 8-bit machine; but in this case, you do not have
11-bit machine bytes, you have 8-bit machine bytes in the
emulated machine on which the C system runs).

In other words, "unsigned char" has no padding bits.
BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.

Right. In practice, they tend to be clumped at one end (e.g., a
la Burroughs A-series machine where "integer" just means "floating
point value with carefully controlled exponent"). The most likely
candidate for "internal" padding bits would be a ones' complement
machine with no native at-least-32 and/or at-least-64 bit types,
where "long" and/or "long long" are made up of several machine
words glued together, with the sign bit unused (and always-0) in
the lower order words. One might do this when implementing C99 on
a Univac 11xx (Unisys? what *are* they called these days?) series
machine, for instance.

Many thanks all of you for helping me to understand the concept.
 
B

Ben Bacarisse

Is it so that a consensus emerges that ^ | & on negative numbers
depend on representation (or, to tell the truth, act on
representations) and so are implementation-defined (although only 3
ways to implement are recognized)?

Well, not many people have expressed a view, and by this time in the
thread I don't think anyone is any doubt about what the various
operations *do*, so the discussion comes down to how the term
"representation" is used.

James Kuyper takes the view that representations only exist in objects
(i.e. when values are stored) but, although that is reasonable meaning
of the term, I don't think that is supported by the wording of the
standard (see my other answer to him in this thread).

In any case, the meaning of ^, |, and & on signed values is most
definitely implementation defined because it depends on the way
negative numbers are represented by the implementation. To me, that
means they are defined in terms of the representation, even though no
storage is involved in an expression like '-1 | -2'. You decide if
you like this meaning of the term.

Is that a consensus? No, but to some extent one can interpret silence
as consent here. Alternatively, since such thing are inherently not
portable, the silence might just mean that no one cares. I certainly
care about this much less then the volume of words I have written
about it suggests -- I'd never use such a construct.
 
B

Ben Bacarisse

James Kuyper said:
Ark Khasin wrote:
...

I can't speak for the consensus; this is just my understanding of what
the standard says. In many cases my understanding differs distinctly
from the consensus understanding.


Those operators don't act on the representations of objects; otherwise
cases like

x += (a+1) | (b-2);

You have written a correct statement because, of course, a+1 is not an
object. The question is, does '(a+1) | (b-2)' depend (or act) on the
representation of 'a+1' and 'b-2' and I'd say it does.

Section 6.2.6 is called "Representations of types" (not objects) and
6.2.6.1 p4 takes some pains to define a new term -- the "object
representation" -- which is not quite the same thing as the
representation of the type.

I don't want to suggest that | operates on padding bits. I don't
think one can determine that either way, but it seems to be pushing the
meaning of representation to its limits (and beyond that used in the
standard) to say that |, &, and ^ act on the value not the
representation.
would be undefined. The way that they operate on or generate negative
values must, however, be consistent with whichever of 3 permitted ways
of handling the sign bits that the implementation chose for the
relevant type.

These "permitted ways" are described in the section called
"Representation of types". Your sentence would be simpler if you had
said that the bits they operate on (and the meaning of the bits that
are produced) are determined by the representation used for signed
integer types.

It is possible to define the result of | on signed types by talking
only about the value of the operands, but it is complicated to do so
and the standard clearly distinguishes between the terms
"representation" and "object representation" so that there is simple
way to understand the operation. The standard uses only few words to
define | (and the others) because the term "corresponding bits" is
clearly intended to refer back to the bits used to represent the
value as described in 6.2.6.
I see no way for those operators to operate on the
padding bits in any sense that is meaningful within the context of the
standard.

I agree, but padding bits are only one part of the representation of
the type.
 
J

James Kuyper

Ben said:
You have written a correct statement because, of course, a+1 is not an
object. The question is, does '(a+1) | (b-2)' depend (or act) on the
representation of 'a+1' and 'b-2' and I'd say it does.

Section 6.2.6 is called "Representations of types" (not objects) and
6.2.6.1 p4 takes some pains to define a new term -- the "object
representation" -- which is not quite the same thing as the
representation of the type.

That is not clear to me. The standard defines what "object
representation" means, but it never defines what "representation" means.
As far as I can tell, the term "representation" is almost always used
in the standard as a short form for "object representation". The
standard uses the term "value representation" exactly once, in
6.2.6.2p2, and oddly enough, while it is worded as a definition, it not
italicized as a definition should be. If it were an official definition,
from context it would appear to be defined only for unsigned types.

When the word "representation" is used without either "object" or
"value" preceding it, I found only a few cases where it was clear that
it was not a reference to the object representation; in every case, it
was also clear that it did not refer to the value representation.
Examples include such things as the representation of characters on the
display screen, or the representation of data in the output file. In
both of those cases, that only thing the standard says is that those are
details outside of its scope.

I'm not saying there's no instances where a lone "representation"
clearly refers to the value representation, where inserting the word
"object" before "representation" would clearly change the intended
meaning. There's too many instances for me to check reliably. However, I
didn't find any - do you know of any?
These "permitted ways" are described in the section called
"Representation of types". Your sentence would be simpler if you had
said that the bits they operate on (and the meaning of the bits that
are produced) are determined by the representation used for signed
integer types.

Which is the way that the standard says the same thing. I don't think
there's a difference in meaning, just a difference in clarity.

....
and the standard clearly distinguishes between the terms
"representation" and "object representation" so that there is simple

Citation, please? The definition of "object representation" does not
clearly distinguish them.
 
B

Ben Bacarisse

James Kuyper said:
That is not clear to me. The standard defines what "object
representation" means, but it never defines what "representation"
means. As far as I can tell, the term "representation" is almost
always used in the standard as a short form for "object
representation".

The section called "Representation of types" includes information
which I think is required in order to put a meaning to expressions
like '-1 | -2'. Without referring to the allowed representations the
term "corresponding bits" in the definition of |, ^ and & has no firm
meaning. That '-1 | -2' is permitted to have one of three different
values depending on information containing in a section about
representations is enough for me.
The standard uses the term "value representation"
exactly once, in 6.2.6.2p2, and oddly enough, while it is worded as a
definition, it not italicized as a definition should be. If it were an
official definition, from context it would appear to be defined only
for unsigned types.

When the word "representation" is used without either "object" or
"value" preceding it, I found only a few cases where it was clear that
it was not a reference to the object representation; in every case, it
was also clear that it did not refer to the value
representation. Examples include such things as the representation of
characters on the display screen, or the representation of data in the
output file. In both of those cases, that only thing the standard says
is that those are details outside of its scope.

I'm not saying there's no instances where a lone "representation"
clearly refers to the value representation, where inserting the word
"object" before "representation" would clearly change the intended
meaning. There's too many instances for me to check reliably. However,
I didn't find any - do you know of any?

If section 6.2.6 was called "Object representation of types" so that
it was unambiguously about how values are stored and nothing else,
then I believe '-1 | -2' would be undefined. If values, not stored in
objects, do not have a representation, then what "bits" are there to
or together? It is because values may be represented as collections
of bits (as it happens in three different ways) that such expressions
can have a meaning defined by combining "corresponding bits".
Which is the way that the standard says the same thing. I don't think
there's a difference in meaning, just a difference in clarity.

...

Citation, please? The definition of "object representation" does not
clearly distinguish them.

I have no other citation than the definition I already cited. I agree
the distinction is not crystal clear, but if your reading of the words
is that there is essentially no difference between "representation"
and "object representation" then how do you give '-1 | -2' a meaning?
You could, of course, say that | (and friends) behaves as if its
operands where stored in objects and the corresponding bits are
combined together, but you'd *still* be referencing the allowed
representations.

The bottom line is that without reference to the allowable
representations, what bits are there for |, ^ and & to operate on?
 
J

James Kuyper

Ben Bacarisse wrote:
....
If section 6.2.6 was called "Object representation of types" so that
it was unambiguously about how values are stored and nothing else,
then I believe '-1 | -2' would be undefined. If values, not stored in
objects, do not have a representation, then what "bits" are there to
or together? It is because values may be represented as collections
of bits (as it happens in three different ways) that such expressions
can have a meaning defined by combining "corresponding bits".

6.5p4 says "Some operators (the unary operator ~, and the binary
operators <<, >>, &, ^, and |, collectively described as bitwise
operators) are required to have operands that have integer type. These
operators yield values that depend on the internal representations of
integers, and have implementation-defined and undefined aspects for
signed types".

As I understand it, that statement about the "internal representations"
refers to the object representation, and does not imply that the
standard attaches any meaning to the representation of a value that is
not currently stored in any C object. It merely requires that the
bitwise operators act on values in such a way that if the resulting
value were saved in an object of that value's type, it would have the
correct bit pattern.

....
I have no other citation than the definition I already cited. I agree
the distinction is not crystal clear, but if your reading of the words
is that there is essentially no difference between "representation"
and "object representation" then how do you give '-1 | -2' a meaning?
You could, of course, say that | (and friends) behaves as if its
operands where stored in objects and the corresponding bits are
combined together, but you'd *still* be referencing the allowed
representations.

That's exactly how I understand it. I never denied that the allowed
representations were referenced, only that the concept of a
representation of a value only aquires a meaning in the event that it is
stored in an object.
 

Ask a Question

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.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top