question about cast

[Yacine]

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well, and why

void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?
Why is it not allowed to cast a pointer to a double in the seconde case ?
Thanks
Yacine

[Christopher Benson-Manica]

Yacine <ya**@netcourrier.com> spoke thus:

void main(){

Hold it right there. Sounds like you could use

http://www.eskimo.com/~scs/C-faq/top.html

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Richard Bos]

Yacine <ya**@netcourrier.com> wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,
Because your implementation is broken, or you're calling it the wrong
way. main() returns int. The cast and subsequent assignment are about as
dubious as Bush Junior's veracity, btw.
void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Because casting a pointer to int is dubious, but possible, while casting
a pointer to double makes no sense at all.

Richard

[Yacine]

Richard Bos wrote:

Yacine <ya**@netcourrier.com> wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,

Because your implementation is broken, or you're calling it the wrong
way. main() returns int. The cast and subsequent assignment are about as
dubious as Bush Junior's veracity, btw.

void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Because casting a pointer to int is dubious, but possible, while casting
a pointer to double makes no sense at all.

Richard

The return type of main has nothing to do with the problem I'm talking
about. My question is: is it possible to cast a pointer to a double ? I
think it does not make more sense to cast a pointer to int than casting
a pointer to double ...

[pete]

Yacine wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,

Because you are not using a conforming implementation of C.
A cast on the left operand of the assignment operator
is a constraint violation.

--
pete

[Yacine]

pete wrote:

Yacine wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,

Because you are not using a conforming implementation of C.
A cast on the left operand of the assignment operator
is a constraint violation.

How can I handle that problem ?

[pete]

Yacine wrote:

pete wrote:

Yacine wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,

Because you are not using a conforming implementation of C.
A cast on the left operand of the assignment operator
is a constraint violation.

How can I handle that problem ?

If you have made sure that there are no alignment problems
and no size problems, then you can

*(int *)&y = x;

If you haven't made sure, then don't do that.

--
pete

[Richard Heathfield]

Yacine wrote:

Does anyone know why

void main()
int main(void)

{ double x;
double *y;
(int) y = x;
}

compiles well,
You can't assign to a value, only to an object. (int)y is a value, not an
object. You should get a diagnostic. Turn up your warning level.
and why

void main()
int main(void)

{ double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Same reason the first one shouldn't. You can't assign to a value, only to an
object. (double)y is a value, not an object.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[pete]

pete wrote:

Yacine wrote:

pete wrote:

Yacine wrote:

>Does anyone know why
>
>void main(){
> double x;
> double *y;
> (int) y = x;
>}
>
>compiles well,
Because you are not using a conforming implementation of C.
A cast on the left operand of the assignment operator
is a constraint violation.
How can I handle that problem ?

If you have made sure that there are no alignment problems
and no size problems, then you can

*(int *)&y = x;

*(int *)&y = (int)x;

Excuse me, I forgot how invloved it was.
If you haven't made sure, then don't do that.

--
pete

[pete]

pete wrote:

pete wrote:

Yacine wrote:

pete wrote:

> Yacine wrote:
>
>>Does anyone know why
>>
>>void main(){
>> double x;
>> double *y;
>> (int) y = x;
>>}
>>
>>compiles well,
>
>
> Because you are not using a conforming implementation of C.
> A cast on the left operand of the assignment operator
> is a constraint violation.
>
How can I handle that problem ?

If you have made sure that there are no alignment problems
and no size problems, then you can

*(int *)&y = x;

*(int *)&y = (int)x;

Excuse me, I forgot how invloved it was.

You also have to make sure that (int)x is an integer value.

--
pete

[Horst Kraemer]

On Thu, 15 Jan 2004 19:02:27 +0100, Yacine <ya**@netcourrier.com>
wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}
This shouldn't compile at all because it isn't C - even if it accepts
"void main()".

In C you can't assign anything to "(int)y" because (int)y is a *value*
and not an object (LValue).
compiles well, and why

void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Idem.

Your compiler uses some extension to the C language. It allows
(int)y=x because sizeof(int)==sizeof y on this platform and it refuses
(double)y=x because sizeof(double)>sizeof y on this platform.

In C the first assignment may be written as

*(int*)&y = x;

and the second as

*(double*)&y = x;

but the behaviour of the second assigment is undefined on your
platform because the type of the left operand is double and sizeof
(double) (probably ==8) > sizeof y (probably ==4). The assigment would
write beyond the memory belonging to y. Moreover a double object may
have different aligment requirements than a

Regards
Horst

[Richard Heathfield]

Yacine wrote:

The return type of main has nothing to do with the problem I'm talking
about.

If you don't want people to point out errors in your code, don't post
erroneous code.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Martin Ambuhl]

Yacine wrote:

Does anyone know why

void main(){ ^^^^
incorrect return type for main double x;
double *y;
(int) y = x; ^^^^
illegal use of a cast where an lvalue is required. }

compiles well,
"Bullshit," you say, "Bullshit!". The above is hopelessly broken.
and why

void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?
For the same reason the first one does *not* "compile well."
Why is it not allowed to cast a pointer to a double in the seconde case ?

For the same reason that your first example is not allowed.

--
Martin Ambuhl

[Martin Ambuhl]

Yacine wrote:

pete wrote:

Yacine wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,

Because you are not using a conforming implementation of C.
A cast on the left operand of the assignment operator
is a constraint violation.

How can I handle that problem ?

Patient: "My arm hurts when I move it like this. What can I do?"
Doctor: "Don't move your arm like that."
--
Martin Ambuhl

[Yacine]

Horst Kraemer wrote:

On Thu, 15 Jan 2004 19:02:27 +0100, Yacine <ya**@netcourrier.com>
wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

This shouldn't compile at all because it isn't C - even if it accepts
"void main()".

In C you can't assign anything to "(int)y" because (int)y is a *value*
and not an object (LValue).

compiles well, and why

void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Idem.

Your compiler uses some extension to the C language. It allows
(int)y=x because sizeof(int)==sizeof y on this platform and it refuses
(double)y=x because sizeof(double)>sizeof y on this platform.

In C the first assignment may be written as

*(int*)&y = x;

and the second as

*(double*)&y = x;

but the behaviour of the second assigment is undefined on your
platform because the type of the left operand is double and sizeof
(double) (probably ==8) > sizeof y (probably ==4). The assigment would
write beyond the memory belonging to y. Moreover a double object may
have different aligment requirements than a

Regards
Horst

Thanks, that the answer I was waiting for

[Keith Thompson]

Yacine <ya**@netcourrier.com> writes:

pete wrote:

Yacine wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,

Because you are not using a conforming implementation of C.
A cast on the left operand of the assignment operator
is a constraint violation.

How can I handle that problem ?

Some other languages, perhaps with names starting with 'C' and
containing punctuation characters, may allow a cast as the left
operand of an assignment operator.

You're trying to do something that doesn't make any sense. The
compiler is preventing you from doing it. I don't see a problem.

Seriously, just what are you trying to do?

Here's the code that the compiler complains about:

double x;
double *y;
(double) y = x; /* illegal */

x is a double; y is a pointer to double.

If you want to make y point to x, you can do this:

y = &x;

If you want to make y point to a float variable with the value of x,
without changing the memory location to which y points, you can do this:

*y = x;

but only after initializing y so it points to a valid memory location.

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

[E. Robert Tisdale]

Yacine wrote:

Horst Kraemer wrote:
[snip]
Thanks, that the answer I was waiting for.

Sorry about your encounters with our "indigenous trolls".
After awhile you'll begin to recognize them and ignore them.

[Chris Torek]

>On Thu, 15 Jan 2004 19:02:27 +0100, Yacine <ya**@netcourrier.com>

wrote: [snippage]

double x;
double *y;
(int) y = x;
In article <9p********************************@4ax.com>
Horst Kraemer <ho***********@epost.de> writes:Your compiler uses some extension to the C language.
This much is reasonably clear (the other "likely" possibility is that
his compiler is simply broken :-) ).
In C the first assignment may be written as

*(int*)&y = x;

Note that one popular compiler that adds a "cast as lvalue" rule,
the GNU C Compiler (gcc), defines cast-as-lvalue *very* differently.
The assignment to (int)y is not equivalent to the above, but rather
to the (syntactically valid but semantically dodgy) ANSI/ISO C code:

(int)(y = (double *)(int)&x)
(double) y = x;

and the second as
*(double*)&y = x;

Gcc would define this as:

(double)(y = (double *)(double)&x)

which would then draw a complaint ("pointer value used where a
floating point value was expected").

For more details on gcc's weird sort-of-like-C language GNUC (which
I pronounce as "ganuck", more or less), see "info gcc", assuming
the info files have been installed along with the compiler. The
definition of lvalue-as-cast is under "C Extensions" and then
"Lvalues".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Peter Nilsson]

pete <pf*****@mindspring.com> wrote in message news:<40***********@mindspring.com>...

pete wrote:

*(int *)&y = x;

*(int *)&y = (int)x;

Excuse me, I forgot how invloved it was.

? The (int) cast is redundant!

'* (int *) &y' forms an lvalue of type int, so the expression x will
be converted to an int on assignment.

--
Peter

[Keith Thompson]

Horst Kraemer <ho***********@epost.de> writes:
[...]

Your compiler uses some extension to the C language. It allows
(int)y=x because sizeof(int)==sizeof y on this platform and it refuses
(double)y=x because sizeof(double)>sizeof y on this platform.

I don't believe the sizes of the various types have anything to do
with this.

In C, a cast is not allowed on the left side of an assignment,
regardless of the types. If a cast is being used as a value (not as
an lvalue), it's legal to convert from a pointer type to an integer
type or vice versa, whether the sizes match or not. It's not legal to
convert between pointer types and floating-point types.

I would guess that the extension implemented by whatever compiler the
OP is using (allowing a cast as an lvalue) would following the same
rules. (As I vaguely alluded to earlier, I think C++ allows casts as
lvalues. I don't know the details, which aren't topical anyway.)

Note that conversions between integers and pointers, though they're
legal, are not usually meaningful. You can convert a pointer to a
sufficiently large integer type (if there is one) and back again and
get the same pointer value. Anything else will probably give you
garbage.

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

[Garma]

Richard Heathfield <do******@address.co.uk.invalid> wrote in message
news:bu**********@hercules.btinternet.com...

Yacine wrote:

Does anyone know why

void main()
int main(void)

{

double x;
double *y;
(int) y = x;
}

compiles well,

You can't assign to a value, only to an object. (int)y is a value, not an
object. You should get a diagnostic. Turn up your warning level.

and why

void main()

int main(void)

{

double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Same reason the first one shouldn't. You can't assign to a value, only to

an object. (double)y is a value, not an object.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

My question may not be related to OP much.
What is an object that is different from value in CO?
Could you elaborate further on "You can't assign to a value, only to an
object."
Thanks!

[Horst Kraemer]

On 15 Jan 2004 21:45:07 GMT, Chris Torek <no****@torek.net> wrote:

On Thu, 15 Jan 2004 19:02:27 +0100, Yacine <ya**@netcourrier.com>
wrote:

[snippage]

double x;
double *y;
(int) y = x;

In article <9p********************************@4ax.com>
Horst Kraemer <ho***********@epost.de> writes:

Your compiler uses some extension to the C language.

This much is reasonably clear (the other "likely" possibility is that
his compiler is simply broken :-) ).

In C the first assignment may be written as

*(int*)&y = x;

Note that one popular compiler that adds a "cast as lvalue" rule,
the GNU C Compiler (gcc), defines cast-as-lvalue *very* differently.
The assignment to (int)y is not equivalent to the above, but rather
to the (syntactically valid but semantically dodgy) ANSI/ISO C code:

(int)(y = (double *)(int)&x)

Apparently it doesn't act according the definition:

For this file

double x=1;
double *y=0;

void f(void)
{
(int)y=x;
}
gcc 3.2 (mingw) produces this output
.file "foo.c"
.globl _x
.data
.align 8
_x:
.long 0
.long 1072693248
.globl _y
.align 4
_y:
.long 0
.text
.align 2
.globl _f
.def _f; .scl 2; .type 32; .endef
_f:
pushl %ebp
movl %esp, %ebp
subl $4, %esp
fldl _x ## load double from _x
fnstcw -2(%ebp)
movw -2(%ebp), %ax
movb $12, %ah
movw %ax, -4(%ebp)
fldcw -4(%ebp)
fistpl _y ## store int to _y
fldcw -2(%ebp)
leave
ret
which converts the double value in &x to int and stores it to &y and
is semantically equivalent to

*(int*)&y = x;

Regards
Horst

[Keith Thompson]

"Garma" <Ga*****@nosysserv.com> writes:
[...]

My question may not be related to OP much.
What is an object that is different from value in CO?
Could you elaborate further on "You can't assign to a value, only to an
object."

(Is "CO" a typo for "C"?)

An object is a variable (more or less; the C standard rarely uses the
term "variable", and an object needn't be modifiable). An object is a
container; the thing it contains is a value.

For example:

int x;
x = 42; /* ok: x is an object */
42 = x; /* illegal: 42 is a value, so you can't assign to it */
(x + 1) = 43; /* illegal: x + 1 is a value, so you can't assign to it */

Look up "lvalue" in your C textbook.

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

[Chris Torek]

>On 15 Jan 2004 21:45:07 GMT, Chris Torek <no****@torek.net> wrote:

Note that one popular compiler that adds a "cast as lvalue" rule,
the GNU C Compiler (gcc), defines cast-as-lvalue *very* differently.
The assignment to (int)y is not equivalent to the above, but rather
to the (syntactically valid but semantically dodgy) ANSI/ISO C code:

(int)(y = (double *)(int)&x)

In article <fk********************************@4ax.com>
Horst Kraemer <ho***********@epost.de> writes:Apparently it doesn't ...
Sorry, I goofed -- I added an "&" that was not in the original
code, of which this is a version:
double x=1;
double *y=0;

void f(void)
{
(int)y=x;
}
Since y has type "double *", the "GCC meaning" is:

(int)(y = (double *)(int)x)

If you compile this:
*(int*)&y = x;

you do indeed get the same machine code, because "int", "int *",
and "double *" all have the same size and format on the x86; and
of course the last quoted C code line above has the same meaning
as:

*(int *)&y = (int)x;

Converting x to int requires code that changes the representation
-- this is the fldl/fistpl instruction pair (the control word store
and reload, fnstcw and fldcw, are red herrings) -- but converting
the resulting "int" to "double *" requires no code on the (32-bit)
Intel (it does require code on IA-64 and the like). This hides
the difference between "then convert int to double *" vs "now just
assign". If you have access to a 64-bit machine, gcc should generate
different code for these two cases (i.e., the two casts then assign
to y, vs the one cast or automatic conversion to assign to *(int *)&y).

(You will also get warnings about converting from 32-bit integers
to 64-bit pointers, where that occurs.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Richard Bos]

Yacine <ya**@netcourrier.com> wrote:

Richard Bos wrote:

Yacine <ya**@netcourrier.com> wrote:

Does anyone know why

void main(){
double x;
double *y;
(int) y = x;
}

compiles well,
Because your implementation is broken, or you're calling it the wrong
way. main() returns int. The cast and subsequent assignment are about as
dubious as Bush Junior's veracity, btw.

void main(){
double x;
double *y;
(double) y = x;
}

does not compile well ?!?

Because casting a pointer to int is dubious, but possible, while casting
a pointer to double makes no sense at all.

The return type of main has nothing to do with the problem I'm talking
about.
You do not know that. Undefined is undefined.
My question is: is it possible to cast a pointer to a double ?
And the obvious answer is "no". As you'd already observed yourself.
I think it does not make more sense to cast a pointer to int than casting
a pointer to double ...

The Standard Committee thought differently, and so do I.

To every address in memory, you can at least assign _some_ kind of index
number. That index number might not make sense in the context of any
other program running on the same computer, or indeed when interpreted
as any other kind of pointer than the original, but it is, at least,
possible, and might in principle be useful to someone doing a very
low-level, system-specific job.
Transforming an address in memory to a floating-point number, however,
does not make sense at all, not even in Gnuck. How, to begin with, would
you map them?

Richard

[Richard Bos]

Horst Kraemer <ho***********@epost.de> wrote:

Your compiler uses some extension to the C language. It allows
(int)y=x because sizeof(int)==sizeof y on this platform and it refuses
(double)y=x because sizeof(double)>sizeof y on this platform.

This does not explain why we _can_ assign longs to ints and vice versa.

Richard

[Horst Kraemer]

On 16 Jan 2004 02:22:15 GMT, Chris Torek <no****@torek.net> wrote:

On 15 Jan 2004 21:45:07 GMT, Chris Torek <no****@torek.net> wrote:

Note that one popular compiler that adds a "cast as lvalue" rule,
the GNU C Compiler (gcc), defines cast-as-lvalue *very* differently.
The assignment to (int)y is not equivalent to the above, but rather
to the (syntactically valid but semantically dodgy) ANSI/ISO C code:

(int)(y = (double *)(int)&x)

In article <fk********************************@4ax.com>
Horst Kraemer <ho***********@epost.de> writes:

Apparently it doesn't ...

Sorry, I goofed -- I added an "&" that was not in the original
code, of which this is a version:

double x=1;
double *y=0;

void f(void)
{
(int)y=x;
}

Since y has type "double *", the "GCC meaning" is:

(int)(y = (double *)(int)x)

OK, the fog clears up. Thanks for your input.

--
Horst

[Dan Pop]

In <bu************@ID-217261.news.uni-berlin.de> Yacine <ya**@netcourrier.com> writes:

about. My question is: is it possible to cast a pointer to a double ?
No, the language does not define such a conversion.
I think it does not make more sense to cast a pointer to int than casting
a pointer to double ...

You're dead wrong. On most implementations using linear addressing,
pointers contain memory addresses which are integers and converting
a pointer to an integer is a run time no-op. Such conversions are often
useful, e.g. when you need to check if a pointer is correctly aligned.

OTOH, converting an address to a floating point type doesn't have much
meaning or use. It's still possible, though, just not directly:
(double)(unsigned long)pointer.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Irrwahn Grausewitz]

"Trollsdale" wrote:

Yacine wrote:

<snip>

Thanks, that the answer I was waiting for.

Sorry about your encounters with our "indigenous trolls".
After awhile you'll begin to recognize them and ignore them.

Whoever bell'd that cat did a good job.
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html