casts and lvalues

[jacob navia]

Continuing the discussion about casts, I would like to know
your opinions about the hairy subject of casts as lvalues, i.e.

int main(void)
{
long long a;
char *n;

(char *)a = n;
}

This will fail under lcc-win32, but MSVC and gcc will
accept it. I know that the standard prescribes the behavior
that lcc-win32 uses, but I left that behavior after a big
discussion about this several years ago. I had modified it,
and some people raised hell.

What are the problems of doing this? I mean not the usual
"the standard says so" but what problems would arise within the
language if this would be accepted?

Apparently gcc and msvc are still used, and this doesn't seem
to produce any big problems.

Thanks in advance for your comments, and I thank all people
that participated in the discussion yesterday.

jacob

[Barry Schwarz]

On Tue, 26 Jun 2007 09:28:14 +0200, jacob navia
<ja***@jacob.re mcomp.frwrote:

>Richard Heathfield wrote:

>CBFalconer said:

>>Richard Heathfield wrote:
CBFalconer said:
Richard Heathfield wrote:

<snip>

>>>>>For example, there is
>no lvalue in the (pointless but legal) statement:
>>
> toupper((unsign ed char)c);
Yes there is, although it is well hidden. The functional parameter.
No, it isn't well hidden. It isn't *there*. Not in that statement.
We must be missing each others points. Where do you think the
conversion of c goes?

It could easily go into a register, but that's beside the point. There's
no object in the statement I presented.

The result of the expression is stored in the stack.

There is an awful lot of generated code that leaves the value of an
evaluated expression in a register without ever placing it in any
memory, let alone a stack.

>(Or its equivalent for the mythical machines without
stack)

I am extremely pleased that my mythical work on the mythical IBM
mainframe results in a very non-mythical paycheck.

>
The object exists, since we can even take its address
within the called function.

Obviously an intermittently true assertion.
Remove del for email

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:

Keith Thompson wrote:

[...]

>What I wrote upthread was:
| No, an argument is an expression whose value is *stored* in an object.
| An argument and the corresponding parameter are two distinct things.

You seemed to disagree with this.

Yes, the evaluation of the argument and the storing of the result in
the parameter always happen together; I suppose they're inseparable
in that sense. But they are two distinct things. An argument is an
expression (see C99 3.3); a parameter is an object (see C99 3.15).
Do you disagree with that?

No, but this discussion is about casting destinations, which cannot
form a LHvalue.

This discussion has drifted considerably. It started out as a
discussion of a proposed extension to allow casts to be treated as
lvalues (presumably if an only if the operand is an lvalue), but this
subthread is about whether a particular expression, a function call,
contains any lvalues.

Do you agree with what I wrote above?
No, an argument is an expression whose value is *stored* in an object.
An argument and the corresponding parameter are two distinct things.

--
Keith Thompson (The_Other_Keit h) 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"