About the typecasting to the LHS

[parag_paul]

Can this be done
float a;
(int) a = getc();

[Walter Roberson]

In article <11*********************@o80g2000hse.googlegroups. com>,
pa********@hotmail.com <pa********@hotmail.comwrote:

>Can this be done
float a;
(int) a = getc();

No, but you could do

(int) (a = getc());

In C, assignments are expressions, so this would do the assignment
first, convert the resulting double to int, and then (because there
is nothing else on the line) throw away the int.

What were you hoping (int) a = getc() to mean? On a number of
platforms, float arithmetic (e.g., silently converting the int returned
by getc() into a float for the assignment) takes place only in
special purpose floating-point registers which cannot be manipulated
as integers.
--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth

[Kenneth Brody]

"pa********@hotmail.com" wrote:

>
Can this be done
float a;
(int) a = getc();

No. (Check your manual and/or this group's archives for a description
of "l-value".)

Well, that and getc() needs a FILE* as an argument. Perhaps you meant
getchar()?

You could use:

a = (float)getchar();

However, the cast to float is unnecessary.

What, exactly, are you _really_ trying to do?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[santosh]

pa********@hotmail.com wrote:

Can this be done
float a;
(int) a = getc();

No. What exactly are you trying to do? Since getc returns an int, assigning
it into floating type and trying to cast it to an int again seems pretty
pointless to me.

[Keith Thompson]

Kenneth Brody <ke******@spamcop.netwrites:

"pa********@hotmail.com" wrote:

>Can this be done
float a;
(int) a = getc();

No. (Check your manual and/or this group's archives for a description
of "l-value".)

"lvalue", without the hyphen, is likely to be a better search term.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[¬a\\/b]

In data Thu, 04 Oct 2007 07:38:18 -0700, parag_paul@ scrisse:

>Can this be done
float a;
(int) a = getc();

float a;
a=getchar();
i think it is be done

[parag_paul]

I am not trying anything.
just trying to understand the scope of typecasting on the left side.
Since I saw some code similar to that.

I was confused initially.
But do you see any potential for the above construct.

@(all who are talking about lvalue)

I am a bit familiar with the concept myself. Just trying to get an
insight from the others on the casting on the left.

[Richard Heathfield]

pa********@hotmail.com said:

I am not trying anything.
just trying to understand the scope of typecasting on the left side.

A cast doesn't of itself yield a modifiable lvalue, so the result of a cast
expression cannot of itself receive an assignment.

Since I saw some code similar to that.

Then it wasn't, strictly speaking, C code.

I was confused initially.
But do you see any potential for the above construct.

Er, no, none at all. Do you? What do you think such a construct would mean?
C doesn't offer a meaning for it, so what meaning do you think it should
have?

@(all who are talking about lvalue)

I am a bit familiar with the concept myself. Just trying to get an
insight from the others on the casting on the left.

I think you need to consider more carefully the responses that you've
received so far. They're telling you something important, but you don't
seem to be getting it. Where a is a float, the expression (int)a = getc()
is simply meaningless. It's not legal C. Not even if we replace getc with
getchar.

Let's see what the compiler makes of it:

me@here:~/scratchcat foo.c
#include <stdio.h>

int main(void)
{
float FloatingPointObject;
(int)FloatingPointObject = getchar();
printf("%f\n", FloatingPointObject);
return 0;
}

me@here:~/scratchmake
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -O2 -g -pg -c -o foo.o foo.c
foo.c: In function `main':
foo.c:6: warning: ANSI C forbids use of cast expressions as lvalues
foo.c:6: warning: value computed is not used

You see? You're just not supposed to do that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

pa********@hotmail.com wrote:

I am not trying anything.
just trying to understand the scope of typecasting on the left side.
Since I saw some code similar to that.

I was confused initially.
But do you see any potential for the above construct.

@(all who are talking about lvalue)

I am a bit familiar with the concept myself. Just trying to get an
insight from the others on the casting on the left.

Remember this: The cast operator is an *operator*. Like
other operators, it takes operands (one, for a cast) and yields
a value. A *value*, not an assignable object.

Given `double x;', all these are nonsense in the same way:

(int)x = 42;
-x = 42;
tan(x) = 42;
&x = malloc(sizeof x);

Clearer now?

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

[Richard Tobin]

In article <Kq******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:

Remember this: The cast operator is an *operator*. Like
other operators, it takes operands (one, for a cast) and yields
a value. A *value*, not an assignable object.

Several operators yield assignable values, * for example, so remembering
that a cast is an operator doesn't necessarily help.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

pa********@hotmail.com said:

>I am not trying anything.
just trying to understand the scope of typecasting on the left side.

A cast doesn't of itself yield a modifiable lvalue, so the result of a cast
expression cannot of itself receive an assignment.

>Since I saw some code similar to that.

Then it wasn't, strictly speaking, C code.

>I was confused initially.
But do you see any potential for the above construct.

Er, no, none at all. Do you? What do you think such a construct would mean?
C doesn't offer a meaning for it, so what meaning do you think it should
have?

[...]

It has no meaning in standard C. That doesn't mean that it has no
*possible* meaning. A compiler may legally implement casts as lvalues
as an extension, as long as it defines the semantics.

gcc does this, though current versions warn about it: "warning: use of
cast expressions as lvalues is deprecated". Note that this means only
it's deprecated *by gcc*; it's never been valid in standard C.

It's a fairly silly extension, since whatever it's supposed to do,
there are clearer ways to do the same thing in standard C. Presumably
the gcc folks realized this and decided to deprecate it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[¬a\\/b]

In data Thu, 11 Oct 2007 05:30:33 -0700, parag_paul scrisse:

>I am not trying anything.
just trying to understand the scope of typecasting on the left side.
Since I saw some code similar to that.

I was confused initially.
But do you see any potential for the above construct.

@(all who are talking about lvalue)

I am a bit familiar with the concept myself. Just trying to get an
insight from the others on the casting on the left.

the cast on the left has a sense only where there is something like
*( obj *)

int b=0;
*(char*)&b=33;

it is not portable etc but sometime is useful

or in the case of compare function for qsort

than it can be useful for write things like

int i;

if( (unsigned)iINT_MAX) ...

in the case INT_MAX is "traslated" to unsigned integer

[Keith Thompson]

"¬a\\/b" <[e-mail]:

In data Thu, 11 Oct 2007 05:30:33 -0700, parag_paul scrisse:

>>I am not trying anything.
just trying to understand the scope of typecasting on the left side.
Since I saw some code similar to that.

I was confused initially.
But do you see any potential for the above construct.

@(all who are talking about lvalue)

I am a bit familiar with the concept myself. Just trying to get an
insight from the others on the casting on the left.

the cast on the left has a sense only where there is something like
*( obj *)

int b=0;
*(char*)&b=33;

it is not portable etc but sometime is useful

or in the case of compare function for qsort

than it can be useful for write things like

int i;

if( (unsigned)iINT_MAX) ...

in the case INT_MAX is "traslated" to unsigned integer

I usually ignore you, but here you've made a simple error. Neither of
your examples is relevant to the discussion, since neither one
attempts to use a cast as an lvalue.

In the first case, ``*(char*)&b=33;'', the cast appears as part of the
expression on the LHS of the assignment, but the full LHS is a
dereference, not a cast. In the second, ``(unsigned)iINT_MAX'', the
cast is the LHS of the ">" operator, not of an assignment.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[¬a\\/b]

In data Sat, 13 Oct 2007 14:27:13 -0700, Keith Thompson scrisse:

>"¬a\\/b" <[e-mail]:

>In data Thu, 11 Oct 2007 05:30:33 -0700, parag_paul scrisse:

>>>I am not trying anything.
just trying to understand the scope of typecasting on the left side.
Since I saw some code similar to that.

I was confused initially.
But do you see any potential for the above construct.

@(all who are talking about lvalue)

I am a bit familiar with the concept myself. Just trying to get an
insight from the others on the casting on the left.

the cast on the left has a sense only where there is something like
*( obj *)

int b=0;
*(char*)&b=33;

it is not portable etc but sometime is useful

or in the case of compare function for qsort

than it can be useful for write things like

int i;

if( (unsigned)iINT_MAX) ...

in the case INT_MAX is "traslated" to unsigned integer

I usually ignore you, but here you've made a simple error. Neither of
your examples is relevant to the discussion, since neither one
attempts to use a cast as an lvalue.

In the first case, ``*(char*)&b=33;'', the cast appears as part of the
expression on the LHS of the assignment, but the full LHS is a
dereference, not a cast. In the second, ``(unsigned)iINT_MAX'', the
cast is the LHS of the ">" operator, not of an assignment.

so where is the differece in your gcc exenstion from
int a=0;
*(char*)&a=43;

and the code
int a=0;
(char)a=43;

[Keith Thompson]

"¬a\\/b" <[e-mail]:

In data Sat, 13 Oct 2007 14:27:13 -0700, Keith Thompson scrisse:

>>"¬a\\/b" <[e-mail]:

[...]

>>it is not portable etc but sometime is useful

or in the case of compare function for qsort

than it can be useful for write things like

int i;

if( (unsigned)iINT_MAX) ...

in the case INT_MAX is "traslated" to unsigned integer

I usually ignore you, but here you've made a simple error. Neither of
your examples is relevant to the discussion, since neither one
attempts to use a cast as an lvalue.

In the first case, ``*(char*)&b=33;'', the cast appears as part of the
expression on the LHS of the assignment, but the full LHS is a
dereference, not a cast. In the second, ``(unsigned)iINT_MAX'', the
cast is the LHS of the ">" operator, not of an assignment.

so where is the differece in your gcc exenstion from
int a=0;
*(char*)&a=43;

and the code
int a=0;
(char)a=43;

It's not *my* gcc extension.

In standard C, a cast is not an lvalue. ``*(char*)&a=42'' is legal;
the cast expression ``(char*)&a'' is the operand of the unary "*"
operator, so it doesn't need to be an lvalue. In ``(char*)a=43'' the
cast is the left operand of an assignment operator, which must be an
lvalue; this is illegal in standard C, but allowed if the compiler
allows casts as lvalues as an extension.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Pfaff]

Kenneth Brody <ke******@spamcop.netwrites:

Then, of course, there is the deprecated(?) "=&" operator.

The =op forms of assignment were listed as anachronisms even in
K&R1, and they aren't in C89 or C99 at all.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Mon, 15 Oct 2007 10:31:48 -0700, Ben Pfaff wrote:

Kenneth Brody <ke******@spamcop.netwrites:

>Then, of course, there is the deprecated(?) "=&" operator.

The =op forms of assignment were listed as anachronisms even in K&R1,
and they aren't in C89 or C99 at all.

Right, and as a result, x=&a is valid C89 and C99, takes the address of
a, and assigns that pointer value to x. If =& were still a single
operator, it would be equally valid, but with a completely different
meaning.

[Ben Pfaff]

Harald van Dijk <tr*****@gmail.comwrites:

On Mon, 15 Oct 2007 10:31:48 -0700, Ben Pfaff wrote:

>Kenneth Brody <ke******@spamcop.netwrites:

>>Then, of course, there is the deprecated(?) "=&" operator.

The =op forms of assignment were listed as anachronisms even in K&R1,
and they aren't in C89 or C99 at all.

Right, and as a result, x=&a is valid C89 and C99, takes the address of
a, and assigns that pointer value to x. If =& were still a single
operator, it would be equally valid, but with a completely different
meaning.

I don't think that "x = &a" and "x &= a" can both be valid for
any given "x" and "a".
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Mon, 15 Oct 2007 12:50:50 -0700, Ben Pfaff wrote:

Harald van Dijk <tr*****@gmail.comwrites:

>On Mon, 15 Oct 2007 10:31:48 -0700, Ben Pfaff wrote:

>>Kenneth Brody <ke******@spamcop.netwrites:

Then, of course, there is the deprecated(?) "=&" operator.

The =op forms of assignment were listed as anachronisms even in K&R1,
and they aren't in C89 or C99 at all.

Right, and as a result, x=&a is valid C89 and C99, takes the address of
a, and assigns that pointer value to x. If =& were still a single
operator, it would be equally valid, but with a completely different
meaning.

I don't think that "x = &a" and "x &= a" can both be valid for any given
"x" and "a".

#include <stdbool.h>

int main(void) {
bool x, a = 0;
x = &a;
x &= a;
return x;
}

Perfectly valid C99 :)

But you are probably correct in C89.

[Kenneth Brody]

$)CHarald van D)&k wrote:

>
On Mon, 15 Oct 2007 12:50:50 -0700, Ben Pfaff wrote:

[...]

I don't think that "x = &a" and "x &= a" can both be valid for any given
"x" and "a".

#include <stdbool.h>

int main(void) {
bool x, a = 0;
x = &a;
x &= a;
return x;
}

Perfectly valid C99 :)

But you are probably correct in C89.

What type is "bool" that it can point to itself? Why doesn't
"x = &a" give a warning for converting "bool *" to "bool"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

$)CHarald van D)&k wrote:

>
On Mon, 15 Oct 2007 10:31:48 -0700, Ben Pfaff wrote:

Kenneth Brody <ke******@spamcop.netwrites:

Then, of course, there is the deprecated(?) "=&" operator.

The =op forms of assignment were listed as anachronisms even in K&R1,
and they aren't in C89 or C99 at all.

Right, and as a result, x=&a is valid C89 and C99, takes the address of
a, and assigns that pointer value to x. If =& were still a single
operator, it would be equally valid, but with a completely different
meaning.

On the other hand, many years ago, I ran into a compiler which took:

mychar=*ptr;

to mean the same as

mychar *= ptr;

Fortunately, this generated an error, as it tried to multiply by a
pointer.

On a related note (sort of), then there's the case of dividing by a
dereferenced pointer:

foo = bar/*ptr;

I learned early on to use spaces around operators, and now I find it
easier to read like that, anyway.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Default User]

Kenneth Brody wrote:

$)CHarald van D)&k wrote:

On Mon, 15 Oct 2007 12:50:50 -0700, Ben Pfaff wrote:

[...]

I don't think that "x = &a" and "x &= a" can both be valid for
any given "x" and "a".

#include <stdbool.h>

int main(void) {
bool x, a = 0;
x = &a;
x &= a;
return x;
}

Perfectly valid C99 :)

But you are probably correct in C89.

What type is "bool" that it can point to itself?

It doesn't point to itself. It converts the pointer to a boolean value.

Why doesn't
"x = &a" give a warning for converting "bool *" to "bool"?

It can take assignment from any scalar type.


Brian

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Mon, 15 Oct 2007 17:59:52 -0400, Kenneth Brody wrote:

$)CHarald van D)&k wrote:

>>
On Mon, 15 Oct 2007 12:50:50 -0700, Ben Pfaff wrote:

[...]

I don't think that "x = &a" and "x &= a" can both be valid for any
given "x" and "a".

#include <stdbool.h>

int main(void) {
bool x, a = 0;
x = &a;
x &= a;
return x;
}

Perfectly valid C99 :)

But you are probably correct in C89.

What type is "bool" that it can point to itself? Why doesn't "x = &a"
give a warning for converting "bool *" to "bool"?

(bool) ptr evaluates to false if ptr is a null pointer, and to true
otherwise. '(bool) ptr' works the same way as '(bool) (ptr != 0)', just
like how 'if (ptr)' works the same way as 'if (ptr != 0)'.

[Ben Pfaff]

Harald van Dijk <tr*****@gmail.comwrites:

>I don't think that "x = &a" and "x &= a" can both be valid for any given
"x" and "a".

#include <stdbool.h>

int main(void) {
bool x, a = 0;
x = &a;
x &= a;
return x;
}

Bravo. You are very clever.
--
"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

[Keith Thompson]

Kenneth Brody <ke******@spamcop.netwrites:

$)CHarald van D)&k wrote:

>>
On Mon, 15 Oct 2007 10:31:48 -0700, Ben Pfaff wrote:

Kenneth Brody <ke******@spamcop.netwrites:

Then, of course, there is the deprecated(?) "=&" operator.

The =op forms of assignment were listed as anachronisms even in K&R1,
and they aren't in C89 or C99 at all.

Right, and as a result, x=&a is valid C89 and C99, takes the address of
a, and assigns that pointer value to x. If =& were still a single
operator, it would be equally valid, but with a completely different
meaning.

On the other hand, many years ago, I ran into a compiler which took:

mychar=*ptr;

to mean the same as

mychar *= ptr;

Fortunately, this generated an error, as it tried to multiply by a
pointer.

[...]

I've used a compiler (VAXC on VMS) that would issue a warning for
x=-y;
In old (pre-K&R) C, this was the syntax for what we would now write
as ``x -= y;'' but of course in K&R C and later it means ``x = -y;''.

The problem was that, after issuing the warning, it compiled it as
``x -= y;''. (And yes, it recognized the modern "-=" operator as well.)

This compiler was in production use in early 1999.

Whitespace is, of course, both the workaround for the ambiguity and a
good idea anyway.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kenneth Brody]

$)CHarald van D)&k wrote:

>
On Mon, 15 Oct 2007 17:59:52 -0400, Kenneth Brody wrote:

$)CHarald van D)&k wrote:

>
On Mon, 15 Oct 2007 12:50:50 -0700, Ben Pfaff wrote:

[...]

I don't think that "x = &a" and "x &= a" can both be valid for any
given "x" and "a".

#include <stdbool.h>

int main(void) {
bool x, a = 0;
x = &a;
x &= a;
return x;
}

Perfectly valid C99 :)

But you are probably correct in C89.

What type is "bool" that it can point to itself? Why doesn't "x = &a"
give a warning for converting "bool *" to "bool"?

(bool) ptr evaluates to false if ptr is a null pointer, and to true
otherwise. '(bool) ptr' works the same way as '(bool) (ptr != 0)', just
like how 'if (ptr)' works the same way as 'if (ptr != 0)'.

So bool is a built-in type (as opposed to a typedef), which can
only hold zero or one, and the assignment:

boolvar = expr;

is equivalent to:

boolvar = ( (expr) != 0 );

(We're talking C99 here.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Tue, 16 Oct 2007 09:48:00 -0400, Kenneth Brody wrote:

$)CHarald van D)&k wrote:

>(bool) ptr evaluates to false if ptr is a null pointer, and to true
otherwise. '(bool) ptr' works the same way as '(bool) (ptr != 0)', just
like how 'if (ptr)' works the same way as 'if (ptr != 0)'.

So bool is a built-in type (as opposed to a typedef),

<stdbool.hdefines bool is a typedef for _Bool. Making bool itself the
built-in type would have broken too much existing code, but to answer the
question I'm pretty sure you meant it, yes, _Bool is a built-in type, not
a typedef for an ordinary integer type.

which can only
hold zero or one, and the assignment:

boolvar = expr;

is equivalent to:

boolvar = ( (expr) != 0 );

(We're talking C99 here.)

Yes. It works with integer types, floating-point types (real, imaginary,
and complex), and pointer types.

[Default User]

Kenneth Brody wrote:

$)CHarald van D)&k wrote:

On Mon, 15 Oct 2007 17:59:52 -0400, Kenneth Brody wrote:

What type is "bool" that it can point to itself? Why doesn't "x
= &a" give a warning for converting "bool *" to "bool"?

(bool) ptr evaluates to false if ptr is a null pointer, and to true
otherwise. '(bool) ptr' works the same way as '(bool) (ptr != 0)',
just like how 'if (ptr)' works the same way as 'if (ptr != 0)'.

So bool is a built-in type (as opposed to a typedef), which can
only hold zero or one, and the assignment:

It is a typedef, for the built-in type _Bool.


Brian