Representation and value
Minti
Date: 2002-01-14 07:56:02 PST
<quote>
A void * object cannot hold a value of any type other than void *.
You can *convert* from a pointer to object or incomplete type to void
*
and back again and get the original value back. But it is important
to realise that the conversion steps in both directions are essential
here.
Conversions can produce a change of representation.
</quote>
But in binary if we see if we have two values with different
representations then only the value is different. Thereby if the value
is same the representations have to be similar or am I missing some
point.
--
Minti.
The above mail accout works unmodified.
Ben Pfaff
> But in binary if we see if we have two values with different
> representations then only the value is different.
Hmm? Two values cannot have the same representation. There must
be a functional mapping from representations to values for an
object of a given type. One representation maps to one value.
> Thereby if the value is same the representations have to be
> similar or am I missing some point.
No. In general there may be more than one representation of a
given value. The value of an object with a given representation
and type is unique, but the representation of a given value is
not necessarily unique.
The canonical example is "negative zero" in sign-magnitude and
ones' complement notation: zero has two representations, but each
of its representations has only the single value zero. Another
example is segmented pointers: there may be many pointer
representations for one address, but a given pointer
representation points to only one address.
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless
David Rubin
I think it has more to do with the type system than with run-time
comparison of actual values.
david
--
If 91 were prime, it would be a counterexample to your conjecture.
-- Bruce Wheeler
Lawrence Kirby
<e87fc4b0.02011...@posting.google.com>
mintiSP...@yahoo.com "Minti" wrote:
>From: Lawrence Kirby (fr...@genesis.demon.co.uk)
>Date: 2002-01-14 07:56:02 PST
><quote>
>A void * object cannot hold a value of any type other than void *.
>You can *convert* from a pointer to object or incomplete type to void
>*
>and back again and get the original value back. But it is important
>to realise that the conversion steps in both directions are essential
>here.
>Conversions can produce a change of representation.
></quote>
>But in binary if we see if we have two values with different
>representations then only the value is different.
Objects are composed of a collection of bits. In C type is what
determines how those bits are interpreted. Integers are interpreted
using some form of binary weighting system. Even there there are
several possibilities, 2's complement, 1's complement and sign magntude
are possible for signed representation and of course there are unsigned
representations too. Floating point types demonstrate a representation
that is *not* based on a simple binary system. There is at the very
least a representation of a mantissa and exponent. The representation
of these doesn't even have to be binary, binary coded decimal is
one alternative.
>Thereby if the value
>is same the representations have to be similar or am I missing some
>point.
The same value can have different representations in different types.
For example 1 is likely to have a different representation in int
and float types. Even different integer types can have different
representations for the same value, although the main difference
is usually the size of the object. I can convert the value 1 stored in
a char variable to long (or any other integer type) and back to char.
The representation may change but the value is the same. I can even convert
to float and back again.
Pointers often all have the same representation (in the sence that if
I convert a pointer value to a different pointer type the represnetation
is unchanged). However C allows different pointer types to have
different representations with certain restrictions. So for example
int * can have a different representation to void *, an int * object
need not even be the same size as a void * object.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Minti
Does the standard guarantee this conversion
char --> int --> long --> long long --> long --> int --> char
If it does not can you provide some example(s) of such implementation(s).
--
Minti
The above mail address works unmodified.
Ben Pfaff
[much snippage because I didn't understand the relevance]
> Does the standard guarantee this conversion
> char --> int --> long --> long long --> long --> int --> char
Does it guarantee it to what? If you mean "does it guarantee
that a value of type char subjected to those conversions retains
its value", the answer is no if char is unsigned and has the same
width as int. In other situations, the answer is yes.
CBFalconer
>
... snip ...
>
> Does the standard guarantee this conversion
> char --> int --> long --> long long --> long --> int --> char
The only guarantee is
T --> void* --> T
with the proviso that char* has the same representation as void*
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Lawrence Kirby
<e87fc4b0.02011...@posting.google.com>
mintiSP...@yahoo.com "Minti" wrote:
...
>Does the standard guarantee this conversion
>char --> int --> long --> long long --> long --> int --> char
Conversions between any 2 integer types always preserve value
whenever that is possible, i.e. when the target type can
represent the original value. Also a higher rank signed integer
type is guaranteed to be able to represent every value that a lower rank
signed integer type can represent. The same is true for higher vs. lower
ranked unsigned integer types (rankwise char < short < int < long <
long long). The only issue here is that plain char can be a signed or an
unsigned type. If it is signed then the origianl char value is
guaranteed to be representable by all of the other types in your
sequence so every step preserves the value. If plain char is unsigned
then it could in theory represent larger positive values than the
signed types above. This is rare in practice but does occur on
some embedded systems. However as long at the original value being
converted is less than INT_MAX for the platform the value will be
preserved.
Lawrence Kirby
cbfal...@yahoo.com "CBFalconer" wrote:
>Minti wrote:
>>
>... snip ...
>>
>> Does the standard guarantee this conversion
>> char --> int --> long --> long long --> long --> int --> char
>
>The only guarantee is
>
> T --> void* --> T
As long as T is a pointer to an object or incomplete type.
>with the proviso that char* has the same representation as void*
Any pointer to character type has the same property as void * in this
respect.
There are plenty of conversions that preserve value, e.g.
function pointer --> different function pointer type -->
original function pointer type
int --> long --> int
float --> double --> float (if the implementation is really conforming :-) )
In the last 2 cases the intermediate value is also usably the same.
Chris Torek
Provided they have the same type, anyway. If you treat a 4 byte
memory object first as an int, and then again as a float, on a
machine where both occupy 4 bytes, they will typically represent
different values.
Of course, doing this in C causes undefined behavior, so unless
someone says "I want to know what this undefined behavior happens
to do on System X", this is all irrelevant. :-) But this is why
I always say that, in C, the first question about any object or
value is its *type*; only then can we talk about its value.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://63.193.109.35/torek/ (not always up) I report spam to abuse@.
"nos...@elf.eng.bsdi.com" *is* my address (one of many actually).