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

[Richard Heathfield]

jacob navia said:

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

It isn't a matter of opinion. They're not legal C. A cast yields a
value, but not an lvalue.

<snip>

What are the problems of doing this?

It doesn't compile.

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

Implementors jumped at C89 like a pack of starving stoats on a squirrel.
But they have stayed away from C99 in droves. I don't see them suddenly
all agreeing to support a particular extension, all with the same
syntax and semantics. So the fundamental problem would be that your
proposal wouldn't be accepted.

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

[Harald van =?UTF-8?B?RMSzaw==?=]

jacob navia wrote:

Continuing the discussion about casts, I would like to know
your opinions about the hairy subject of casts as lvalues, i.e.
[...]
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?

int a = 1;
void f(double *d) {
if (a == 1) *d = 2;
if (a == 2) *d = 0;
}
int main(void) {
f(&(double) a);
return a;
}

What would this program return?

[Joe Wright]

Harald van Dijk wrote:

jacob navia wrote:

>Continuing the discussion about casts, I would like to know
your opinions about the hairy subject of casts as lvalues, i.e.
[...]
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?

int a = 1;
void f(double *d) {
if (a == 1) *d = 2;
if (a == 2) *d = 0;
}
int main(void) {
f(&(double) a);
return a;
}

What would this program return?

It doesn't compile here. You seem to want to pretend a is a double.

f((double*)&a);

will at least compile.

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

[jacob navia]

Richard Heathfield wrote:

jacob navia said:

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

It isn't a matter of opinion. They're not legal C. A cast yields a
value, but not an lvalue.

<snip>

>What are the problems of doing this?

It doesn't compile.

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

Implementors jumped at C89 like a pack of starving stoats on a squirrel.
But they have stayed away from C99 in droves. I don't see them suddenly
all agreeing to support a particular extension, all with the same
syntax and semantics. So the fundamental problem would be that your
proposal wouldn't be accepted.

But this is just politics. I do not want to do any proposal nor do
I want to modify anything. I just want to know what TECHNICAL problems
could arise if that extension (that is provided at least by the
compilers I mentioned) would be part of the language.

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

[Richard Tobin]

In article <46************ **********@news .orange.fr>,

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

(char *)a = n;
}

>This will fail under lcc-win32, but MSVC and gcc will
accept it.

Gcc has, I think, always warned about this if you give enough flags,
and seems to reject it by default in recent versions.

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

So long as you can specifiy exactly what it means, there would be no
problem adding it to the language. Of course, once you've specified
exactly what it means it's easy enough to manage without it.

I've always thought its use in implementing a "program counter"
variable was reasonable, where a generic pointer is cast to various
types and incremented by the same amount, e.g.

op = *((operator *)pc)++;
switch(op)
{
...
case ADD:
arg1 = *((int *)pc)++;
arg2 = *((int *)pc)++;
whatever = arg1 + arg2;
...

But those writing this style of code can easily enough work around it.

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

Apparently gcc's implementors see sufficient problems to not accept it
by default, but those problems may just be compatibility ones.

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

[Mark McIntyre]

On Sun, 24 Jun 2007 23:20:03 +0200, in comp.lang.c , jacob navia
<ja***@jacob.re mcomp.frwrote:

(of
long long a;
char *n;

(char *)a = n;
)

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

Because its meaningless in my view. What exactly does the above do?

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

[Keith Thompson]

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;

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

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

[jacob navia]

Mark McIntyre wrote:

On Sun, 24 Jun 2007 23:20:03 +0200, in comp.lang.c , jacob navia
<ja***@jacob.re mcomp.frwrote:

(of
long long a;
char *n;

(char *)a = n;
)

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

Because its meaningless in my view. What exactly does the above do?

Moves the contents of n (an address) into the memory locations of a,
that can hold a pointer is sizeof(void *) <= sizeof(long long);

I am not saying that this is nice/the best thing since sliced bread
but that is what it does.

[jacob navia]

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?