double casts

[Martijn]

Hi,

Those familiar with Windows programming may be familiar with the windowsx.h
header. In this header macros exist that use double casts, like so (hope
this is readable):

#define ComboBox_LimitT ext(hwndCtl,cch Limit) \

((int)(DWORD)Se ndMessage((hwnd Ctl),CB_LIMITTE XT,(WPARAM)(int )(cchLimit),0))

Why is this? Does this help in typechecking? (I would think not).

Thanks for the info,

--
Martijn
http://www.sereneconcepts.nl

[Jack Klein]

On Sun, 2 Nov 2003 13:33:05 +0100, "Martijn"
<su************ *********@hotNO FILTERmail.com> wrote in comp.lang.c:

Hi,

Those familiar with Windows programming may be familiar with the windowsx.h
header. In this header macros exist that use double casts, like so (hope
this is readable):
Your text is readable, the concept of what the code is doing is not.
#define ComboBox_LimitT ext(hwndCtl,cch Limit) \

((int)(DWORD)Se ndMessage((hwnd Ctl),CB_LIMITTE XT,(WPARAM)(int )(cchLimit),0))

Why is this? Does this help in typechecking? (I would think not).
Casts never help in type checking, they specifically exist to defeat
type checking.
Thanks for the info,

For a variety of reasons, Windows header files are a complete and
total mess. If you really want to delve into the details, I'd suggest
a Windows programming group or one of Microsoft's support groups.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[xarax]

"Jack Klein" <ja*******@spam cop.net> wrote in message
news:on******** *************** *********@4ax.c om...

On Sun, 2 Nov 2003 13:33:05 +0100, "Martijn"
<su************ *********@hotNO FILTERmail.com> wrote in comp.lang.c:

Hi,

Those familiar with Windows programming may be familiar with the windowsx.h
header. In this header macros exist that use double casts, like so (hope
this is readable):

Your text is readable, the concept of what the code is doing is not.

#define ComboBox_LimitT ext(hwndCtl,cch Limit) \

((int)(DWORD)Se ndMessage((hwnd Ctl),CB_LIMITTE XT,(WPARAM)(int )(cchLimit),0))

Why is this? Does this help in typechecking? (I would think not).

Casts never help in type checking, they specifically exist to defeat
type checking.

Thanks for the info,

For a variety of reasons, Windows header files are a complete and
total mess. If you really want to delve into the details, I'd suggest
a Windows programming group or one of Microsoft's support groups.

That wasn't his question.

His question is this: When is it necessary, if ever, to use
a double cast?

For example:

1. (WPARM)(int)(cc hLimit)

2. (WPARM)(cchLimi t)

Are these two expressions *always* equivalent? Is there ever
a situation where the intermediate cast (int) is necessary
to get a "correct" final cast to (WPARM)?

Just ignore whatever "WPARM" is supposed to be and think
about the generic question of double casting versus single casting.
Don't get distracted about Windows. This is really a C question.

For you C gurus out there, what is the definitive answer?

[Joona I Palaste]

xarax <xa***@email.co m> scribbled the following:

"Jack Klein" <ja*******@spam cop.net> wrote in message
news:on******** *************** *********@4ax.c om...

On Sun, 2 Nov 2003 13:33:05 +0100, "Martijn"
<su************ *********@hotNO FILTERmail.com> wrote in comp.lang.c:

> Hi,
>
> Those familiar with Windows programming may be familiar with the windowsx.h
> header. In this header macros exist that use double casts, like so (hope
> this is readable):
Your text is readable, the concept of what the code is doing is not.

> #define ComboBox_LimitT ext(hwndCtl,cch Limit) \
>
> ((int)(DWORD)Se ndMessage((hwnd Ctl),CB_LIMITTE XT,(WPARAM)(int )(cchLimit),0))
>
> Why is this? Does this help in typechecking? (I would think not).

Casts never help in type checking, they specifically exist to defeat
type checking.

> Thanks for the info,

For a variety of reasons, Windows header files are a complete and
total mess. If you really want to delve into the details, I'd suggest
a Windows programming group or one of Microsoft's support groups.

That wasn't his question. His question is this: When is it necessary, if ever, to use
a double cast? For example: 1. (WPARM)(int)(cc hLimit) 2. (WPARM)(cchLimi t) Are these two expressions *always* equivalent? Is there ever
a situation where the intermediate cast (int) is necessary
to get a "correct" final cast to (WPARM)? Just ignore whatever "WPARM" is supposed to be and think
about the generic question of double casting versus single casting.
Don't get distracted about Windows. This is really a C question. For you C gurus out there, what is the definitive answer?

I am not a C guru and cannot answer the OP's question, but I can say
for certain that in general, an expression of the type (A)(B)something
is not the same thing as (A)something.
Proof:
int i;
int *p1 = (int *)&i;
int *p2 = (int *)(long)&i;
p1 is guaranteed to store i's address. p2 is not.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"We're women. We've got double standards to live up to."
- Ally McBeal

[Keith Thompson]

Joona I Palaste <pa*****@cc.hel sinki.fi> writes:
[...]

I am not a C guru and cannot answer the OP's question, but I can say
for certain that in general, an expression of the type (A)(B)something
is not the same thing as (A)something.
Proof:
int i;
int *p1 = (int *)&i;
int *p2 = (int *)(long)&i;
p1 is guaranteed to store i's address. p2 is not.

Ok, that's a good example of when a double cast is harmful. Are there
any cases where it's helpful -- i.e., where (A)(B)something differs
from (A)something *and* (A)(B)something does something useful that
(A)something does not. In other words, if I see (A)(B)something in
source code, can I always delete the "(B)" without breaking anything?

Here's one example (assume 8-bit char):

unsigned int n = 257;
float f0 = (float)n; /* f0 == 257.0 */
float f1 = (float)(unsigne d char)n; /* f1 == 1.0 */

Are there any examples not involving deliberate loss of information?

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[CBFalconer]

xarax wrote:

"Jack Klein" <ja*******@spam cop.net> wrote in message

"Martijn" <su************ *********@hotNO FILTERmail.com> wrote:

Those familiar with Windows programming may be familiar with
the windowsx.h header. In this header macros exist that use
double casts, like so (hope this is readable):

#define ComboBox_LimitT ext(hwndCtl,cch Limit) \

((int)(DWORD)Se ndMessage((hwnd Ctl),CB_LIMITTE XT,(WPARAM)(int )(cchLimit),0))

Why is this? Does this help in typechecking? (I would think
not).

Casts never help in type checking, they specifically exist to
defeat type checking.

For a variety of reasons, Windows header files are a complete
and total mess. If you really want to delve into the details,
I'd suggest a Windows programming group or one of Microsoft's
support groups.

That wasn't his question.

His question is this: When is it necessary, if ever, to use
a double cast?

For example:

1. (WPARM)(int)(cc hLimit)
2. (WPARM)(cchLimi t)

Are these two expressions *always* equivalent? Is there ever
a situation where the intermediate cast (int) is necessary
to get a "correct" final cast to (WPARM)?

Just ignore whatever "WPARM" is supposed to be and think
about the generic question of double casting versus single
casting. Don't get distracted about Windows. This is really
a C question.

For you C gurus out there, what is the definitive answer?

One possibility that occurs to me is when you don't know the
signedness of the original item. Thus you might need:

(size_t) ((unsigned char) ch)

which could avoid generating a large number from '\0xff', say.

However the essential illegitimacy of windows headers remains :-)

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Sheldon Simms]

On Sun, 02 Nov 2003 20:45:22 +0000, Keith Thompson wrote:

Joona I Palaste <pa*****@cc.hel sinki.fi> writes:
[...]

I am not a C guru and cannot answer the OP's question, but I can say
for certain that in general, an expression of the type (A)(B)something
is not the same thing as (A)something.
Proof:
int i;
int *p1 = (int *)&i;
int *p2 = (int *)(long)&i;
p1 is guaranteed to store i's address. p2 is not.

Ok, that's a good example of when a double cast is harmful. Are there
any cases where it's helpful -- i.e., where (A)(B)something differs
from (A)something *and* (A)(B)something does something useful that
(A)something does not. In other words, if I see (A)(B)something in
source code, can I always delete the "(B)" without breaking anything?

Here's one example (assume 8-bit char):

unsigned int n = 257;
float f0 = (float)n; /* f0 == 257.0 */
float f1 = (float)(unsigne d char)n; /* f1 == 1.0 */

Are there any examples not involving deliberate loss of information?

I have some code that uses a few double casts, but they rely on
implementation-defined behavior -- specifically that an unsigned
integer cast to a signed integer becomes the signed integer value
with the same bit value as the unsigned integer.

i.e.:
unsigned char uc = 255;
signed char sc = (signed char)uc;
/* sc has value -1 */

The code does things like this:

short s;
unsigned char uca, ucb;
...
++uca; /* increment with intended wrap from 255 to 0 */
...
--ucb; /* decrement with intended wrap from 0 to 255 */
...
s = (short)(signed char)uca + (short)(signed char)ucb;

The (signed char) casts are necessary to force the two
values being added into the range -128..+127 and the (short)
casts are necessary to prevent problems when the sum would
overflow a signed char.

[Peter Nilsson]

Sheldon Simms <sh**********@y ahoo.com> wrote in message news:<pa******* *************** ******@yahoo.co m>...
....

unsigned char uc = 255;
signed char sc = (signed char)uc;
/* sc has value -1 */

There is no standard guarantee that sc has the value -1.

If 255 <= SCHAR_MAX, then sc gets the value 255, otherwise 255 is
converted in an implementation defined way. [C99 allows an
implementation defined signal to be raised, although that's highly
unlikely.]

--
Peter

[Sheldon Simms]

On Sun, 02 Nov 2003 18:05:24 -0800, Peter Nilsson wrote:

Sheldon Simms <sh**********@y ahoo.com> wrote in message news:<pa******* *************** ******@yahoo.co m>...
...

unsigned char uc = 255;
signed char sc = (signed char)uc;
/* sc has value -1 */

There is no standard guarantee that sc has the value -1.

If 255 <= SCHAR_MAX, then sc gets the value 255, otherwise 255 is
converted in an implementation defined way. [C99 allows an
implementation defined signal to be raised, although that's highly
unlikely.]

Thanks for pointing that out, even though I had already said that
my code relied on implementation defined behavior. Since you didn't
bother quoting it, here's what I said:

I have some code that uses a few double casts, but they rely on
implementation-defined behavior

-Sheldon

[Peter Nilsson]

"Sheldon Simms" <sh**********@y ahoo.com> wrote in message
news:pa******** *************** *****@yahoo.com ...

On Sun, 02 Nov 2003 18:05:24 -0800, Peter Nilsson wrote:

Sheldon Simms <sh**********@y ahoo.com> wrote in message news:<pa******* *************** ******@yahoo.co m>...

...

unsigned char uc = 255;
signed char sc = (signed char)uc;
/* sc has value -1 */

There is no standard guarantee that sc has the value -1.

If 255 <= SCHAR_MAX, then sc gets the value 255, otherwise 255 is
converted in an implementation defined way. [C99 allows an
implementation defined signal to be raised, although that's highly
unlikely.]

Thanks for pointing that out, even though I had already said that
my code relied on implementation defined behavior.

Since you didn't bother quoting it, here's what I said:

It's not that I didn't bother; I wanted to isolate the specific code that my
comment referred to.

I have some code that uses a few double casts, but they rely on
implementation-defined behavior
Continued by...
--specifically that an unsigned
integer cast to a signed integer becomes the signed integer value
with the same bit value as the unsigned integer.

Which isn't actually enough to give sc the value -1, even on an 8 bit char
implementation. You need the further assumption of two's complement.

Even implementation specific code is worth analysing from the point of view
of trying to make it (and similar code) non implementation dependant. To do
that, we (or at least I) need to discus what those dependancies are, i.e.
what the standards guarantee, and what they don't. For me, that is the whole
point of comp.lang.c.

In any case, I apologise if you feel I misrepresented you by taking your
post too far out of context.

--
Peter