Why it is not an lvalue ?

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Jun 20, 2005.

  1. Guest

    Consider the following piece of code:

    (char *)0x100; /* I know that converting an integer to pointer
    type is implementation defined. But forget
    this for a moment */
    My question is,
    Why the above expression is not an lvalue ? It both specifies the
    the storage location as well as the type of object ?

    When I try to increment it
    (char *)0x100++;
    I get the error, that it is not an lvalue.
    , Jun 20, 2005
    #1
    1. Advertising

  2. writes:
    > Consider the following piece of code:
    >
    > (char *)0x100; /* I know that converting an integer to pointer
    > type is implementation defined. But forget
    > this for a moment */
    > My question is,
    > Why the above expression is not an lvalue ? It both specifies the
    > the storage location as well as the type of object ?
    >
    > When I try to increment it
    > (char *)0x100++;
    > I get the error, that it is not an lvalue.


    The result of a cast is never an lvalue. A cast takes its operand (an
    expression) and converts it to the specified type; the result does not
    designate an object.

    In the example above, you take the expression 0x100 and convert it to
    type char*. Do you expect to change the value of 0x100?

    If you apply the unary "*" operator to it, the result is an lvalue.
    For example:

    *(char*)0x100 ++;

    In this case, the object being incremented is the char value at
    address 0x100.

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Jun 20, 2005
    #2
    1. Advertising

  3. Tim Rentsch Guest

    Keith Thompson <> writes:

    > writes:
    > > Consider the following piece of code:
    > >
    > > (char *)0x100; /* I know that converting an integer to pointer
    > > type is implementation defined. But forget
    > > this for a moment */
    > > My question is,
    > > Why the above expression is not an lvalue ? It both specifies the
    > > the storage location as well as the type of object ?
    > >
    > > When I try to increment it
    > > (char *)0x100++;
    > > I get the error, that it is not an lvalue.

    >
    > The result of a cast is never an lvalue. A cast takes its operand (an
    > expression) and converts it to the specified type; the result does not
    > designate an object.
    >
    > In the example above, you take the expression 0x100 and convert it to
    > type char*. Do you expect to change the value of 0x100?
    >
    > If you apply the unary "*" operator to it, the result is an lvalue.
    > For example:
    >
    > *(char*)0x100 ++;
    >
    > In this case, the object being incremented is the char value at
    > address 0x100.


    Keith must not have gotten enough to eat earlier and be suffering
    from low blood sugar. If he had he surely would have written
    that the expression in question is parsed as though it were

    (char *) (0x100++);

    which doesn't work because a constant can't be incremented. To
    increment the char at location 0x100, use

    (*(char *)0x100) ++;

    or

    ++ *(char *)0x100;

    or

    *(char *)0x100 += 1;

    Incidentally, it's easy to see that (char *)0x100 can't be an
    lvalue, because it can't appear on the left side of an assignment
    operator. This

    (char *)0x100 = 0;

    isn't allowed; whereas, this

    *(char *)0x100 = 0;

    is.
    Tim Rentsch, Jun 20, 2005
    #3
  4. Richard Bos Guest

    wrote:

    > Consider the following piece of code:
    >
    > (char *)0x100; /* I know that converting an integer to pointer
    > type is implementation defined. But forget
    > this for a moment */
    > My question is,
    > Why the above expression is not an lvalue ? It both specifies the
    > the storage location as well as the type of object ?


    No, it doesn't. It specifies _a_ storage location, but not the location
    where (char *)0x100 is stored.

    > When I try to increment it
    > (char *)0x100++;
    > I get the error, that it is not an lvalue.


    That's because you're trying to increment what is, essentially, only an
    intermediate value. There is nowhere for that value to be written to.

    I suspect that your real intent was to increment not the value _of_
    (char *)0x100, but the value _at_ (char *)0x100. If so, you need another
    level of indirection.

    Richard
    Richard Bos, Jun 20, 2005
    #4
  5. pete Guest

    Lawrence Kirby wrote:
    >
    > On Mon, 20 Jun 2005 01:07:35 -0700, Tim Rentsch wrote:
    >
    > ...
    >
    > > Incidentally, it's easy to see that (char *)0x100 can't be an
    > > lvalue, because it can't appear on the left side of an assignment
    > > operator.

    >
    > Given
    >
    > const char ch;
    >
    > ch is an lvalue that can't appear on the left side of an assignment.


    Here's my nonrigorous attempt at a new defintion for lvalue:
    There are two kinds of lvalues.
    1 A primary expression which is the identifier of an object
    is an lvalue.
    2 An expression which is the result of an indirection operation,
    is an lvalue.

    An expression which is the result of any of the following
    operators, would be an lvalue.
    * (indirection operator)
    -> (structure/union pointer operator)
    [ ] (array subscript operator)


    --
    pete
    pete, Jun 20, 2005
    #5
  6. Tim Rentsch Guest

    Lawrence Kirby <> writes:

    > On Mon, 20 Jun 2005 01:07:35 -0700, Tim Rentsch wrote:
    >
    > ...
    >
    > > Incidentally, it's easy to see that (char *)0x100 can't be an
    > > lvalue, because it can't appear on the left side of an assignment
    > > operator.

    >
    > Given
    >
    > const char ch;
    >
    > ch is an lvalue that can't appear on the left side of an assignment.


    Right. I should have said that the other way - if something
    isn't an lvalue, it can't go on the left side of an assignment
    statement. Sadly there doesn't seem to be a simple means of
    identifying lvalues the way assignment does for modifiable
    lvalues.
    Tim Rentsch, Jun 20, 2005
    #6
  7. On Mon, 20 Jun 2005 01:07:35 -0700, Tim Rentsch wrote:

    ....

    > Incidentally, it's easy to see that (char *)0x100 can't be an
    > lvalue, because it can't appear on the left side of an assignment
    > operator.


    Given

    const char ch;

    ch is an lvalue that can't appear on the left side of an assignment.

    Lawrence
    Lawrence Kirby, Jun 20, 2005
    #7
  8. <posted & mailed>

    literals can't be lvalues. It's perfectly logical. What's the sense of:

    5++;

    .... are you attemptin to say "all number 5's are now 6's"? No. There's no
    variable that's being changed...

    wrote:

    > Consider the following piece of code:
    >
    > (char *)0x100; /* I know that converting an integer to pointer
    > type is implementation defined. But forget
    > this for a moment */
    > My question is,
    > Why the above expression is not an lvalue ? It both specifies the
    > the storage location as well as the type of object ?
    >
    > When I try to increment it
    > (char *)0x100++;
    > I get the error, that it is not an lvalue.


    --
    Remove '.nospam' from e-mail address to reply by e-mail
    James McIninch, Jun 20, 2005
    #8
  9. On Mon, 20 Jun 2005 10:07:59 +0000, pete wrote:

    ....

    > Here's my nonrigorous attempt at a new defintion for lvalue:


    The standard is really merssed up over the definition of lvalue,
    but the basic concept is that an lvalue is an expression that
    designates an object.

    > There are two kinds of lvalues.
    > 1 A primary expression which is the identifier of an object
    > is an lvalue.


    A string literal i.e. "..." in the source code is an lvalue.

    > 2 An expression which is the result of an indirection operation,
    > is an lvalue.


    Unless the operand is a pointr to a function or pointer to void.

    > An expression which is the result of any of the following
    > operators, would be an lvalue.
    > * (indirection operator)
    > -> (structure/union pointer operator)
    > [ ] (array subscript operator)


    Those are all examples of indirection. The structure/union member
    selection operator . also produces an lvalue result if its
    operand is an lvalue.

    Lawrence
    Lawrence Kirby, Jun 20, 2005
    #9
  10. pete Guest

    Lawrence Kirby wrote:
    >
    > On Mon, 20 Jun 2005 10:07:59 +0000, pete wrote:
    >
    > ...
    >
    > > Here's my nonrigorous attempt at a new defintion for lvalue:

    >
    > The standard is really merssed up over the definition of lvalue,
    > but the basic concept is that an lvalue is an expression that
    > designates an object.
    >
    > > There are two kinds of lvalues.
    > > 1 A primary expression which is the identifier of an object
    > > is an lvalue.

    >
    > A string literal i.e. "..." in the source code is an lvalue.
    >
    > > 2 An expression which is the result of an indirection operation,
    > > is an lvalue.

    >
    > Unless the operand is a pointr to a function or pointer to void.
    >
    > > An expression which is the result of any of the following
    > > operators, would be an lvalue.
    > > * (indirection operator)
    > > -> (structure/union pointer operator)
    > > [ ] (array subscript operator)

    >
    > Those are all examples of indirection. The structure/union member
    > selection operator . also produces an lvalue result if its
    > operand is an lvalue.


    Thank you.

    --
    pete
    pete, Jun 20, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Biber

    Re: Why is this not a modifiable lvalue.

    Simon Biber, Jun 27, 2003, in forum: C Programming
    Replies:
    0
    Views:
    2,341
    Simon Biber
    Jun 27, 2003
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,737
    Smokey Grindel
    Dec 2, 2006
  3. Kavya
    Replies:
    9
    Views:
    493
    Dik T. Winter
    Oct 28, 2006
  4. Replies:
    11
    Views:
    682
    James Kuyper
    Sep 22, 2008
  5. Julian Mehnle
    Replies:
    0
    Views:
    226
    Julian Mehnle
    Jul 17, 2003
Loading...

Share This Page