two meanings of a cast

[Felix Kater]

I haven't been thinking about it for years but recently I've stumbled on
the fact that 'casting' is actually doing (at least) two different
things:

On the one hand 'casting' means: 'Change something into somthing
else'. Example: double d=9.99; long l=(double)d;

On the other hand 'casting' means: 'Treating something as something
else without change'. For instance when casting function pointers.

Would You agree?

IMO this difference between 'conversion' and 'treatment' isn't probably
pointed out enough to C newcomers and may be one reason for the danger
of casts.

Felix

[Chris Dollin]

Felix Kater wrote:

I haven't been thinking about it for years but recently I've stumbled on
the fact that 'casting' is actually doing (at least) two different
things:

On the one hand 'casting' means: 'Change something into somthing
else'. Example: double d=9.99; long l=(double)d;

On the other hand 'casting' means: 'Treating something as something
else without change'. For instance when casting function pointers.

Would You agree?

No.

In a cast expression `(T) E`, we're requiring the value of the expression
`E` to be converted to type `T` using the appropriate conversion machinery.

That's true everywhere.

Sometimes, the "appropriat e conversion machinery" leaves the underlying
bit-pattern unchanged, leading to the illusion that the cast means "Treat
something as something else without change". But this is an accident of
implementation.

[We have seen in the past that conversion from say `char*` to `int*` and
back requires bit-fiddling code in some implementations .]

IMO this difference between 'conversion' and 'treatment' isn't probably
pointed out enough to C newcomers and may be one reason for the danger
of casts.

I don't think it's as simple as that. I suspect the danger comes from
casts of pointers and a belief that if `p` points somewhere sane then
the pointer `(T*) p` points somewhere equally sane and is dereferencable
to get values of type `T`.

--
Nit-picking is best done among friends.

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Charlton Wilbur]

>>>>"FK" == Felix Kater <fk****@googlem ail.comwrites:

FKOn the one hand 'casting' means: 'Change something into
FKsomthing else'. Example: double d=9.99; long l=(double)d;

FKOn the other hand 'casting' means: 'Treating something as
FKsomething else without change'. For instance when casting
FKfunction pointers.

FKWould You agree?

No; in your first case, you're also "treating something as something
else without change." The value of d does not change when you cast it
to a double (completely unnecessary, since that's what it is) and
assign it to l.

Charlton

--
Charlton Wilbur
cw*****@chromat ico.net

[pemo]

On Apr 27, 1:23 pm, Chris Dollin <chris.dol...@h p.comwrote:

<snip>

Sometimes, the "appropriat e conversion machinery" leaves the underlying
bit-pattern unchanged, leading to the illusion that the cast means "Treat
something as something else without change". But this is an accident of
implementation.

<snip>

Are you saying here that there exists an implementation that would
alter the bit pattern of an object as it is cast [keeping the
original's size constant] - or that the change in bits would likely be
the result of changing the size of the original?

[Eric Sosman]

Felix Kater wrote:

I haven't been thinking about it for years but recently I've stumbled on
the fact that 'casting' is actually doing (at least) two different
things:

On the one hand 'casting' means: 'Change something into somthing
else'. Example: double d=9.99; long l=(double)d;

That's fine, although it's a silly cast. `d' is already
a `double', so "converting " it to a `double' is unnecessary.
(The `double' result, whether "converted" or not, will then
be converted to `long' for initializing `l'.)

On the other hand 'casting' means: 'Treating something as something
else without change'. For instance when casting function pointers.

Would You agree?

No. A cast is an operator that performs a conversion (even
if the conversion is vacuous, as above). There is no such thing
as a "let's pretend" cast.

However, casts can convert a pointer of one type into a pointer
to another type, and there is something like a "let's pretend"
effect if the converted result is then used to access a pointed-
to object or function:

int i = 42;
unsigned char *p = (unsigned char*) &i;
printf ("The individual bytes of %d are:", i);
while (p < (unsigned char*)(&i + 1))
printf (" %d", *p++);
printf ("\n");

Line two takes the pointer-to-int value `&i' and converts
it to a pointer-to-unsigned-char, which it then stores in `p'.
There is no "let's pretend" at all: A value is converted from one
type to another, and that's that.

There's another such conversion on line four, where another
pointer-to-int is converted to pointer-to-unsigned-char for
purposes of comparison. Again, there's no "let's pretend:" the
cast converts the value `(&i + 1)' to a different type.

The "let's pretend" occurs on line five, where a pointer
to one type (unsigned char) is used to manipulate an object of
a different type (int). Observe that there is no cast in line
five: We are "treating something as something else without
change" by accessing it with different kinds of pointers, not
by applying a cast to it. (No cast is ever applied to `i'.)

IMO this difference between 'conversion' and 'treatment' isn't probably
pointed out enough to C newcomers and may be one reason for the danger
of casts.

It would be a disservice to newcomers to point out a difference
that doesn't exist. For the same reason, most introductory texts
omit mentioning the temperatures of C's data types.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Felix Kater]

On Fri, 27 Apr 2007 13:23:31 +0100
Chris Dollin <ch**********@h p.comwrote:

Sometimes, the "appropriat e conversion machinery" leaves the
underlying bit-pattern unchanged, leading to the illusion that the
cast means "Treat something as something else without change". But
this is an accident of implementation.

Some notes:

'sometimes': This is exactly what I mean--from a students view. Talking
about casts does not give you the clue if data is converted or not.

'illusion': In practice it *is* a big difference if you can or cannot
cast something into somthing else and back again without having changed
a single byte. So calling it an illusion wouldn't help.

'accident of implementation' : I wonder if there aren't cases in which
legal casts could simply never be 'conversions' nor make sense
as such in any implementation. So, this was reason why casts are ment
not to be conversions sometimes.

Felix

[Felix Kater]

On Fri, 27 Apr 2007 08:58:24 -0400
Eric Sosman <es*****@acm-dot-org.invalidwrot e:

Example: double d=9.99; long l=(double)d;

'd' is already a `double', so "converting " it to a `double' is
unnecessary.

True, that was a silly mistake: I meant:
Example: double d=9.99; long l=(long)d;

Felix

[Army1987]

"pemo" <pe*********@gm ail.comha scritto nel messaggio
news:11******** **************@ c18g2000prb.goo glegroups.com.. .

Are you saying here that there exists an implementation that would
alter the bit pattern of an object as it is cast [keeping the
original's size constant] - or that the change in bits would likely be
the result of changing the size of the original?

If sizeof(int) equals sizeof(float), do you expect

int i = SOME_INTEGER_CO NSTANT;
float f = (float)i;

!memcmp(&i, &f, sizeof i)

to always be true, on *any* implementation?

[Chris Dollin]

pemo wrote:

On Apr 27, 1:23 pm, Chris Dollin <chris.dol...@h p.comwrote:

>Sometimes, the "appropriat e conversion machinery" leaves the underlying
bit-pattern unchanged, leading to the illusion that the cast means "Treat
something as something else without change". But this is an accident of
implementation .

Are you saying here that there exists an implementation that would
alter the bit pattern of an object as it is cast [keeping the
original's size constant] - or that the change in bits would likely be
the result of changing the size of the original?

No, I'm saying that sometimes the conversion doesn't alter the bitpattern,
so looking at the bitpattern gives the illusion that the cast doesn't
really do anything.

(EG one could play with `unsigned char *` to discover the values of the
bytes and that the bytes of the converted value were equal to the bytes
of the original value; or one could read the assembler output of a
I-can-do-assembler-output compiler.)

This will happen with eg casting ints to longs and vice-versa on machines
where they're the same size, and often happens with casting between
object pointer values.

--
"Who do you serve, and who do you trust?" /Crusade/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Chris Dollin]

Felix Kater wrote:

On Fri, 27 Apr 2007 13:23:31 +0100
Chris Dollin <ch**********@h p.comwrote:

>Sometimes, the "appropriat e conversion machinery" leaves the
underlying bit-pattern unchanged, leading to the illusion that the
cast means "Treat something as something else without change". But
this is an accident of implementation.

Some notes:

'sometimes': This is exactly what I mean--from a students view. Talking
about casts does not give you the clue if data is converted or not.

Excuse me, it does: the data is /always/ converted.

Sometimes the implementation of the conversion is trivial and preserves
the bit-pattern. Doesn't matter: the value has been converted.

'illusion': In practice it *is* a big difference if you can or cannot
cast something into somthing else and back again without having changed
a single byte.

Some conversions are lossless; some are not. Just because /sometimes/
the implementation doesn't have to do anything doesn't mean it always
won't.

If you stick to what the Standard guarantees, you won't write code
where your round-tripping is surprising.

I'd like examples of your "In practice it *is* a big difference".

So calling it an illusion wouldn't help.

'accident of implementation' : I wonder if there aren't cases in which
legal casts could simply never be 'conversions' nor make sense
as such in any implementation. So, this was reason why casts are ment
not to be conversions sometimes.

It's not the reason, because they're not sometimes-not-conversions.

--
"Possibly you're not recalling some of his previous plans." Zoe, /Firefly/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England