P
parag_paul
Can this be done
float a;
(int) a = getc();
float a;
(int) a = getc();
W
Walter Roberson
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.
K
Kenneth Brody
[email protected] said:
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:[email protected]>
S
santosh
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.
K
Keith Thompson
Kenneth Brody said:
"lvalue", without the hyphen, is likely to be a better search term.
¬
¬a\\/b
In data Thu, 04 Oct 2007 07:38:18 -0700, parag_paul@ scrisse:
float a;
a=getchar();
i think it is be done
float a;
a=getchar();
i think it is be done
P
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.
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.
R
Richard Heathfield
(e-mail address removed) said:
A cast doesn't of itself yield a modifiable lvalue, so the result of a cast
expression cannot of itself receive an assignment.
Then it wasn't, strictly speaking, C code.
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?
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:~/scratch> cat foo.c
#include <stdio.h>
int main(void)
{
float FloatingPointObject;
(int)FloatingPointObject = getchar();
printf("%f\n", FloatingPointObject);
return 0;
}
me@here:~/scratch> make
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.
A cast doesn't of itself yield a modifiable lvalue, so the result of a cast
expression cannot of itself receive an assignment.
Then it wasn't, strictly speaking, C code.
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?
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:~/scratch> cat foo.c
#include <stdio.h>
int main(void)
{
float FloatingPointObject;
(int)FloatingPointObject = getchar();
printf("%f\n", FloatingPointObject);
return 0;
}
me@here:~/scratch> make
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.
E
Eric Sosman
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?
R
Richard Tobin
Eric Sosman said:
Several operators yield assignable values, * for example, so remembering
that a cast is an operator doesn't necessarily help.
-- Richard
K
Keith Thompson
[...]Richard Heathfield said:
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.
¬
¬a\\/b
In data Thu, 11 Oct 2007 05:30:33 -0700, parag_paul scrisse:
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)i> INT_MAX) ...
in the case INT_MAX is "traslated" to unsigned integer
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)i> INT_MAX) ...
in the case INT_MAX is "traslated" to unsigned integer
K
Keith Thompson
¬a\\/b said:
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)i> INT_MAX'', the
cast is the LHS of the ">" operator, not of an assignment.
F
Francine.Neary
Interesting...
This would be a fun interview question to help sort out the women from
the girls:
"What's wrong with the following code:
int a=0;
int *p=NULL;
p++=&a;
a) Nothing
b) Constraint violation: p++ is not a modifiable lvalue
c) Undefined behavior: arithmetic on a null pointer
d) Undefined behavior: p is modified twice with no intervening
sequence point
e) Some combination of the above"
¬
¬a\\/b
In data Sat, 13 Oct 2007 14:27:13 -0700, Keith Thompson scrisse:
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;
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;
K
Keith Thompson
¬a\\/b said:
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.
K
Kenneth Brody
This would be a fun interview question to help sort out the women from
the girls:
"What's wrong with the following code:
int a=0;
int *p=NULL;
p++=&a;
a) Nothing
b) Constraint violation: p++ is not a modifiable lvalue
c) Undefined behavior: arithmetic on a null pointer
d) Undefined behavior: p is modified twice with no intervening
sequence point
e) Some combination of the above"
Well, given that "p++" is not an l-value, the rest of the choices
are irrelevent.
Yes, "p++" when p is NULL is UB, but since the entire statement is
invalid because of the "p++ is not an l-value" issue, does it really
matter?
And, since "p++" is not an l-value, the statement doesn't modify
p twice without an intervening sequence point.[1]
Finally, is "only b" considered a "combination of the above"?
Given that you can have a "combination" of one, I say "yes".
Now, when I first read it, I was wondering about the lack of any
whitespace in "p++=&a" statement. My first inclination was that
this was a trick question because it was really the "++=" operator,
until I remembered that there is no "++=" operator. (D'oh!)
Then, of course, there is the deprecated(?) "=&" operator.
[1] I almost use "w/o" for without, but I didn't want anyone saying
that "w" and "o" aren't defined, so you can't divide them.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
B
Ben Pfaff
Kenneth Brody said:
The =op forms of assignment were listed as anachronisms even in
K&R1, and they aren't in C89 or C99 at all.
?
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F
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.
B
Ben Pfaff
Harald van Dijk said:
I don't think that "x = &a" and "x &= a" can both be valid for
any given "x" and "a".