Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > casts and lvalues

Reply
Thread Tools

casts and lvalues

 
 
Mark McIntyre
Guest
Posts: n/a
 
      06-25-2007
On Mon, 25 Jun 2007 00:25:32 +0200, in comp.lang.c , jacob navia
<(E-Mail Removed)> wrote:

>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
 
Reply With Quote
 
 
 
 
Mark McIntyre
Guest
Posts: n/a
 
      06-25-2007
On 24 Jun 2007 22:23:51 GMT, in comp.lang.c , http://www.velocityreviews.com/forums/(E-Mail Removed)
(Richard Tobin) wrote:

>In article <(E-Mail Removed)>,
>Mark McIntyre <(E-Mail Removed)> wrote:
>

(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
 
Reply With Quote
 
 
 
 
Joe Wright
Guest
Posts: n/a
 
      06-25-2007
jacob navia wrote:
> Keith Thompson wrote:
>> jacob navia <(E-Mail Removed)> writes:
>>> 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+(struct 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 ---
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      06-25-2007
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((unsigned 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.securityfocus.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

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      06-25-2007
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((unsigned 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
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      06-26-2007
"Joe Wright" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      06-26-2007
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((unsigned 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.securityfocus.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

 
Reply With Quote
 
Dik T. Winter
Guest
Posts: n/a
 
      06-26-2007
In article <(E-Mail Removed)> Jack Klein <(E-Mail Removed)> writes:
> On Sun, 24 Jun 2007 21:13:40 +0200, jacob navia
> <(E-Mail Removed)> wrote 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, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      06-26-2007
CBFalconer said:
> Richard Heathfield wrote:
>> CBFalconer said:
>>> Richard Heathfield wrote:

<snip>
>>>> For example, there is
>>>> no lvalue in the (pointless but legal) statement:
>>>>
>>>> toupper((unsigned 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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-26-2007
CBFalconer <(E-Mail Removed)> writes:
> 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((unsigned 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_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Casts on lvalues BartC C Programming 74 12-17-2012 09:37 PM
lvalues and rvalues Nicklas Karlsson C Programming 127 05-05-2010 10:58 PM
Lvalues and Rvalues ramasubramanian.rahul@gmail.com C Programming 3 10-14-2006 09:55 PM
Avoiding "use of cast expressions in lvalues is deprecated" steve.j.donovan@gmail.com C Programming 23 09-21-2006 05:45 PM
lvalues -> incomplete types Mantorok Redgormor C Programming 7 02-07-2004 03:45 PM



Advertisments