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

[Mark McIntyre]

On Mon, 25 Jun 2007 00:25:32 +0200, in comp.lang.c , jacob navia
<ja***@jacob.re mcomp.frwrote:

>if I would add support for it, are there any TECHNICAL drawbacks?

I guess the point is, nobody commenting here can currently see any
actual purpose for adding it. Before asking if there are any technical
drawbacks, one needs to first ascertain a use.

Imagine you're a car designer. Do you ask "is there a technical
drawback with adding a beach umbrella on the steering wheel?" or do
first you ask why....
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On 24 Jun 2007 22:23:51 GMT, in comp.lang.c , ri*****@cogsci. ed.ac.uk
(Richard Tobin) wrote:

>In article <ft************ *************** *****@4ax.com>,
Mark McIntyre <ma**********@s pamcop.netwrote :

(replying to Jabob's comment)

>>>Why are casts not lvalues? What TECHNICAL reasons exist for that?
That is my question.

>>Because its meaningless in my view.

C constructs are no natural phenomena. They are meaningful if people
assign meaning to them.

Philosophy is all very well...

>And several compilers *have* assigned meaning
to casts as lvalues,

Yes, but the point is in my view that meaning is meaningless.
IYSWIM...

>>What exactly does the above do?

I believe that it's intended to be equivalent to "a = (long long)n'.
As such, it's not very useful.

Quite

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Joe Wright]

jacob navia wrote:

Keith Thompson wrote:

>jacob navia <ja***@jacob.re mcomp.frwrites:

>>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?

[...]

This extension doesn't seem to me to be particularly useful. The
above would be more clearly written as:

long long a;
char *n;
a = (long long)n;

Granted.

It is clearer but the question is not if this is pleasing but if there
would be any problems (in the sense of contradictions or buggy language
specifications) if casts could be lvalues.

>Another problem with this, as with any extension, is that it
encourages programmers to write non-portable code that depends on it.

Yes, of course. lcc-win32 doesn't even support this extension. But
if I would add support for it, are there any TECHNICAL drawbacks?
I mean, if somebody asks me to support overloading addition
with

int operator+(struc t FOO *a,int b);

I would say NO that can't be done because addition of a pointer and
an integer is already used in the language to access the nth element
using a pointer as base, i.e.
struct FOO *p;
p + 6
addresses the sixth element after the element pointed by p. If I would
implement such an extension I would introduce an ambiguity in the
language.

Is that the case with casts as lvalues?

Well, an lvalue expression tells us where the object is so that we might
store a value there. The current value stored in the object may be of no
interest at all. Let's imagine we have two 4-byte int objects in memory
at address 200.

200 : int a
204 : int b

Neither a nor b is initialized. Their values are indeterminate.

a = 1;

The expression a is an lvalue because the compiler knows it's at 200 and
so knows where to store the value 1.

b = a;

The expression b is an lvalue at address 204. The expression a is now
simply the value 1 to be stored in the location defined by lvalue b.

In C, a cast is an explicit conversion of a value from one type to
another. The result is a value of the destination type. What would we
expect of..

(short)a = b:

...whether gcc 'allows' it or not? C89 apparently does not allow it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>jacob navia wrote:

>>>

... snip ...

>>>
Why are casts not lvalues? What TECHNICAL reasons exist for that?
That is my question.

A cast requires a destination (i.e. a lvalue) to receive the
converted object.

No, it doesn't. No object is converted by a cast, and casts do not
*require* lvalues to receive their results. 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.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

>>jacob navia wrote:

... snip ...

Why are casts not lvalues? What TECHNICAL reasons exist for that?
That is my question.

A cast requires a destination (i.e. a lvalue) to receive the
converted object.

No, it doesn't. No object is converted by a cast, and casts do not
*require* lvalues to receive their results. 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.

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

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Richard Heathfield wrote:

>>CBFalconer said:
jacob navia wrote:
>
... snip ...
>
Why are casts not lvalues? What TECHNICAL reasons exist for that?
That is my question.

A cast requires a destination (i.e. a lvalue) to receive the
converted object.

No, it doesn't. No object is converted by a cast, and casts do not
*require* lvalues to receive their results. 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? All the elements of the library have to be
available as functions, and macros (if provided) can only mimic a
function call.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[Stephen Sprunk]

"Joe Wright" <jo********@com cast.netwrote in message
news:nK******** *************** *******@comcast .com...

Well, an lvalue expression tells us where the object is so that we might
store a value there. The current value stored in the object may be of no
interest at all. Let's imagine we have two 4-byte int objects in memory at
address 200.

....

In C, a cast is an explicit conversion of a value from one type to
another. The result is a value of the destination type. What would we
expect of..

(short)a = b:

..whether gcc 'allows' it or not? C89 apparently does not allow it.

Logically, it would be equivalent to (i.e. shorthand for) the expression:

*(short *)&a = b;

However, doing that is generally a bad idea for several different reasons,
and I am philosophically opposed to making bad ideas easier to express.
They should stand out in code, not be made invisible.

There's also the argument that most of the features added in C99 were
extensions that were widely implemented and oconsidered to add value; given
that the GCC folks initially implemented but then deprecated this feature,
and GCC is one of the most widely used compilers, that doesn't bode well for
this being added to the next revision of C. It also doesn't appear to add
any value, since you can already accomplish the same bad idea today if you
really want to.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Dik T. Winter]

In article <qa************ *************** *****@4ax.comJa ck Klein <ja*******@spam cop.netwrites:

On Sun, 24 Jun 2007 21:13:40 +0200, jacob navia
<ja***@jacob.re mcomp.frwrote in comp.lang.c:

....

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?

What do you do with:
(char *)(3LL + 5LL) = n;
...???

More interesing:
char a;
(long *) a = 0;
Or in general, what if a cast changes the representation?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard Heathfield]

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.

All the elements of the library have to be
available as functions, and macros (if provided) can only mimic a
function call.

Yes, but the statement I presented is not a function definition. It is
merely a function call.

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

[Keith Thompson]

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

Richard Heathfield wrote:

>CBFalconer said:

>>Richard Heathfield wrote:
CBFalconer said:
jacob navia wrote:
>>
... snip ...
>>
>Why are casts not lvalues? What TECHNICAL reasons exist for that?
>That is my question.
>
A cast requires a destination (i.e. a lvalue) to receive the
converted object.

No, it doesn't. No object is converted by a cast, and casts do not
*require* lvalues to receive their results. 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? All the elements of the library have to be
available as functions, and macros (if provided) can only mimic a
function call.

There's an lvalue in the expression, but not the one that anyone has
mentioned. Assuming c is a declared object, c (the argument of the
cast) is an lvalue; it's just not used in a context that requires an
lvalue, so it's converted to a non-lvalue, yielding the current value
of c. (I don't remember where the standard specifies this
conversion.)

The *parameter* of the toupper function is an object, and a reference
to that object is an lvalue, but any such reference can only be within
the definition of the toupper function; it's not on the line in
question. In the call, we merely have an *argument*, which is just an
expression (that doesn't happen to be an lvalue).

Note that the identifier toupper itself is not an lvalue, since it
designates a function, not an object.

(If toupper is defined as a macro, then the expression to which the
call expands could include any number of lvalues.)

As for the proposed extension, I presume that a cast expression would
be an lvalue if and only if the operand is an lvalue.

--
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"