Velocity Reviews > The result of ++ is not an lvalue?

# The result of ++ is not an lvalue?

lovecreatesbea...@gmail.com
Guest
Posts: n/a

 05-20-2007
K&R2, both sec A7.3.4 Postfix Incrementation and secA.7.4.1 Prefix
Incrementation Operators say that "The result is not an lvalue". Is
this correct? I don't see an errata on these points. If below the p++
or ++p is not an lvalue, then *p++ or *++p is a syntax error.

When it talks about Unary Operators, why doesn't the secA7.4 collect
both the prefix and postfix incrementation operators together?

int main(void)
{
char a[10] = {0}, *p = a;

/* a[0] = 'a'; a[1] = 'b'; */
/* *p = 'a'; *(p+1) = 'b'; */
/* *p = 'a'; *p++ = 'b'; p--; */
*p = 'a'; *++p = 'b'; p--;
return 0;
}

Martin Ambuhl
Guest
Posts: n/a

 05-20-2007
(E-Mail Removed) wrote:
> K&R2, both sec A7.3.4 Postfix Incrementation and secA.7.4.1 Prefix
> Incrementation Operators say that "The result is not an lvalue". Is
> this correct?

Yes. The result is a value, and specifies nothing about where it is.
An lvalue must have a location associated with it.

> I don't see an errata on these points.

Errata are reserved for errors. Why should there be an erratum for
something not in error?

> If below the p++
> or ++p is not an lvalue, then *p++ or *++p is a syntax error.

Really? Why would you claim that?
When p is a pointer, the result of p++ or ++p is a pointer value which
can of course be dereferenced. Why would you think that only lvalues
can be dereferenced? The '*' indirection operator is applied to
expressions, not just lvalues.

> When it talks about Unary Operators, why doesn't the secA7.4 collect
> both the prefix and postfix incrementation operators together?

The choice of presentation is up to the authors. We are not mind
readers nor responsible for their choices. Ask them. I'm not even sure
what your question means. Certainly in K&R1 (A.7.2 Unary Operators) the
++lvalue, lvalue--, lvalue++, and lvalue-- are about as close to each
other as is physically possible.

>
> int main(void)
> {
> char a[10] = {0}, *p = a;
>
> /* a[0] = 'a'; a[1] = 'b'; */
> /* *p = 'a'; *(p+1) = 'b'; */
> /* *p = 'a'; *p++ = 'b'; p--; */
> *p = 'a'; *++p = 'b'; p--;
> return 0;
> }
>

Keith Thompson
Guest
Posts: n/a

 05-20-2007
"(E-Mail Removed)" <(E-Mail Removed)> writes:
> K&R2, both sec A7.3.4 Postfix Incrementation and secA.7.4.1 Prefix
> Incrementation Operators say that "The result is not an lvalue". Is
> this correct?

Absolutely.

> I don't see an errata on these points. If below the p++
> or ++p is not an lvalue, then *p++ or *++p is a syntax error.

No, the operand of the unary "*" operator doesn't need to be an
lvalue; it just needs to be a pointer value.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(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"

jg
Guest
Posts: n/a

 05-20-2007
On May 19, 10:48 pm, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> K&R2, both sec A7.3.4 Postfix Incrementation and secA.7.4.1 Prefix
> Incrementation Operators say that "The result is not an lvalue". Is
> this correct? I don't see an errata on these points. If below the p++

Yes, the result is not an lvalue.

> or ++p is not an lvalue, then *p++ or *++p is a syntax error.
>

No. That (p++) isn't an lvalue means that there is no way to
change (p++), and doesn't mean (p++) cannot be dereferenced.

Let's see p = 1, (p++) is also 1. This '1' cannot be changed
in the way that any variable is changed because this '1' does not
have lvalue. You can't do (p++) = 2, for example.

Richard Heathfield
Guest
Posts: n/a

 05-20-2007
Keith Thompson said:

<snip>

> No, the operand of the unary "*" operator doesn't need to be an
> lvalue; it just needs to be a pointer value.

....which must be of object or function type, and which must actually
point to an object or function.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Malcolm McLean
Guest
Posts: n/a

 05-20-2007

"(E-Mail Removed)" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> K&R2, both sec A7.3.4 Postfix Incrementation and secA.7.4.1 Prefix
> Incrementation Operators say that "The result is not an lvalue". Is
> this correct? I don't see an errata on these points. If below the p++
> or ++p is not an lvalue, then *p++ or *++p is a syntax error.
>
> When it talks about Unary Operators, why doesn't the secA7.4 collect
> both the prefix and postfix incrementation operators together?
>
> int main(void)
> {
> char a[10] = {0}, *p = a;
>
> /* a[0] = 'a'; a[1] = 'b'; */
> /* *p = 'a'; *(p+1) = 'b'; */
> /* *p = 'a'; *p++ = 'b'; p--; */
> *p = 'a'; *++p = 'b'; p--;
> return 0;
> }
>

The postfix operators are bit unsusal in that they have high binding
precedence but are applied last.
This allows for concise code in loops

while(*ptr++);

will step through a zero-terminated array, for instance, setting ptr to the
position after the last member.

What this means is that *ptr++ = 0;
sets *ptr to 0, then increments ptr.

However my thinking is moving away from this type of code. Generally now I
put an increment / decrement on its own line. If you've got to think about
how precedence resolves, the code is unnecessarily hard to read.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Chris Dollin
Guest
Posts: n/a

 05-20-2007
Malcolm McLean wrote:

(fx:snip)

> This allows for concise code in loops
>
> while(*ptr++);
>
> will step through a zero-terminated array, for instance, setting ptr to
> the position after the last member.
>
> What this means is that *ptr++ = 0;
> sets *ptr to 0, then increments ptr.
>
> However my thinking is moving away from this type of code. Generally now I
> put an increment / decrement on its own line. If you've got to think about
> how precedence resolves, the code is unnecessarily hard to read.

Or you haven't learnt the idioms.

`*p++` is a C idiom, widely used. You should no more need to
think about how precedence resolves to use it than you should
in `a + b * c`.

[ie, you have to learn it /sometime/, but once learnt, it's
like riding a bicycle -- balancing becomes natural, and you
should always wear a helment in case of accide.]

--
Oops I Did It Hedgehog

pete
Guest
Posts: n/a

 05-20-2007
(E-Mail Removed) wrote:

> If below the p++
> or ++p is not an lvalue, then *p++ or *++p is a syntax error.

Wrong.

There is no requirment for the operand of unary *,
to be an lvalue.

Example:
(p[0]) means the exact same thing as (*(p + 0)).
(p + 0) is not an lvalue.
You can't have ((p + 0) = 0).

--
pete

Richard Heathfield
Guest
Posts: n/a

 05-20-2007
Malcolm McLean said:

<snip>

> What this means is that *ptr++ = 0;
> sets *ptr to 0, then increments ptr.

No, it doesn't. ++ has higher precedence, and so it is the value of
ptr++ that is provided as the operand to *. Of course, the value of
ptr++ is the value that ptr had at the previous sequence point.

The precise order in which stuff happens is up to the implementation, of
course, but the Standard requires the semantics of the expression to be
as I have described.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Eric Sosman
Guest
Posts: n/a

 05-20-2007
(E-Mail Removed) wrote:
> K&R2, both sec A7.3.4 Postfix Incrementation and secA.7.4.1 Prefix
> Incrementation Operators say that "The result is not an lvalue". Is
> this correct? I don't see an errata on these points. If below the p++
> or ++p is not an lvalue, then *p++ or *++p is a syntax error.

No. *(any_valid_pointer_expression) is an lvalue, whatever
the status of any_valid_pointer_expression itself.

Even if it were an error, it wouldn't be a syntax error.
There is nothing syntactically wrong with ++TheAnswer = 43;
the semantics are what doom it.

> When it talks about Unary Operators, why doesn't the secA7.4 collect
> both the prefix and postfix incrementation operators together?

You'd need to ask K or R for their exact reasons, but it
seems plausible that they separated the postfix operators from
the prefix operators because the postfix operators are not in
the same class and have a higher precedence. Oddly enough,
the Standard makes the same separation.

--
Eric Sosman
(E-Mail Removed)lid