Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

The result of ++ is not an lvalue?

 
 
Eric Sosman
Guest
Posts: n/a
 
      05-20-2007
Malcolm McLean wrote:
>
> The postfix operators are bit unsusal in that they have high binding
> precedence but are applied last.


This is complete nonsense.

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


Wrong again. The time when ptr is incremented is not
specified; indeed, the incrementation may take "macroscopic
time" and overlap with other operations bracketed by the
same pair of sequence points. Regardless of the scheduling
of the increment, though, the value of ptr++ is defined
as the value of ptr as it was before the ++ operator caused
any change. That value is what the * operator uses, and
the lvalue produced by * is what the = operator uses. Neither
the = nor the * use the "current" value of ptr in any way.

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


The third sentence is true, but if "you've got to think"
about precedence when reading something as simple as *p++, it
means your ability to read C has not yet transcended the level
of "LOOK, JANE. SEE SPOT. SEE SPOT RUN."

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid



 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      05-21-2007
Richard Heathfield <(E-Mail Removed)> writes:

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


What?

Are you really telling me that the most famous string copy in the world
doesn't work im comp.lang.c land?

while(*dest++=*src++);

or you making life difficult for human beings again?

His text above is pretty clear and makes sense.

*ptr is indeed set to 0 and then (in terms of this sentence) ptr is
incremented.

Or?!?!?! Am I losing my senses?


 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      05-21-2007
Richard said:

> Richard Heathfield <(E-Mail Removed)> writes:
>
>> 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.

>
> What?
>
> Are you really telling me that the most famous string copy in the
> world doesn't work im comp.lang.c land?
>
> while(*dest++=*src++);


Not at all. If you think so, you have misinterpreted what I wrote.

> or you making life difficult for human beings again?


Not at all. I'm actually trying to make life /easier/, by making clear
what the Standard actually guarantees about the expression *ptr++ = 0;

> His text above is pretty clear and makes sense.


Sure. It's just wrong, that's all, although this isn't quite as clear
from the quoted text alone as from the article in which it was
originally said:

"The postfix operators are bit unsusal in that they have high binding
precedence but are applied last."

That was the viewpoint he was trying to explain, and that viewpoint is
incorrect.

> *ptr is indeed set to 0 and then (in terms of this sentence) ptr is
> incremented.


That isn't guaranteed by the Standard. For example, the following
pseudo-assembly-language would be a perfectly legal translation:

MOV tmp, ptr
INC ptr
MOV *tmp, 0

In other words, the increment can happen first, and the update
afterwards. Whether this actually happens depends on the implementor.
The Standard certainly permits it.

> Or?!?!?! Am I losing my senses?


I couldn't possibly comment.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      05-21-2007

"Richard Heathfield" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Richard said:
>
>> Richard Heathfield <(E-Mail Removed)> writes:
>>
>>> 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.

>>
>> What?
>>
>> Are you really telling me that the most famous string copy in the
>> world doesn't work im comp.lang.c land?
>>
>> while(*dest++=*src++);

>
> Not at all. If you think so, you have misinterpreted what I wrote.
>
>> or you making life difficult for human beings again?

>
> Not at all. I'm actually trying to make life /easier/, by making clear
> what the Standard actually guarantees about the expression *ptr++ = 0;
>
>> His text above is pretty clear and makes sense.

>
> Sure. It's just wrong, that's all, although this isn't quite as clear
> from the quoted text alone as from the article in which it was
> originally said:
>
> "The postfix operators are bit unsusal in that they have high binding
> precedence but are applied last."
>
> That was the viewpoint he was trying to explain, and that viewpoint is
> incorrect.
>

Explain. Not define.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      05-21-2007
On May 21, 2:18 am, Eric Sosman <(E-Mail Removed)> wrote:
>
> No. *(any_valid_pointer_expression) is an lvalue, whatever
> the status of any_valid_pointer_expression itself.


Except when it doesn't designate an object (e.g. if
the any_valid_pointer_expression is pointing one off
the end of an array).

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      05-21-2007
Old Wolf wrote On 05/21/07 17:31,:
> On May 21, 2:18 am, Eric Sosman <(E-Mail Removed)> wrote:
>
>> No. *(any_valid_pointer_expression) is an lvalue, whatever
>>the status of any_valid_pointer_expression itself.

>
>
> Except when it doesn't designate an object (e.g. if
> the any_valid_pointer_expression is pointing one off
> the end of an array).


One thing about c.l.c. is that verbal shortcuts always
catch up with one ... I used "valid" suggestively rather
than precisely, and dangitall if'n somebody didn't call me
on it.

Another way a perfectly good pointer value can fail to
be "valid" in my imprecise sense is to be a pointer to an
incomplete type, e.g., a `void*' or a `struct opaque*'.
Such a pointer can be perfectly well-defined, useful, and
a model citizen in every way, yet not be capable of yielding
an lvalue.

And if somebody nit-picks that `struct opaque' might
not be an incomplete type, I'm gonna boot up my DS9K and
do some DAMAGE!

http://dialspace.dial.pipex.com/town/green/gfd34/art/

--
(E-Mail Removed)
 
Reply With Quote
 
Harald van D k
Guest
Posts: n/a
 
      05-21-2007
Old Wolf wrote:
> On May 21, 2:18 am, Eric Sosman <(E-Mail Removed)> wrote:
> >
> > No. *(any_valid_pointer_expression) is an lvalue, whatever
> > the status of any_valid_pointer_expression itself.

>
> Except when it doesn't designate an object (e.g. if
> the any_valid_pointer_expression is pointing one off
> the end of an array).


Even then, and rightly so. Just imagine, otherwise whether

static void inc(int *p) {
++*p;
}

is a constraint violation (remember, a diagnostic is required for
constraint violations) depends on what values of p will be passed to
it at runtime.

 
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
i = 10; result = ++i - --i; How result become ZERO Lakshmi Sreekanth C Programming 52 09-23-2010 07:41 AM
Re: i = 10; result = ++i - --i; How result become ZERO Mr. Buffoon C Programming 4 09-23-2010 03:01 AM
Is the result of valid dynamic cast always equal to the result ofcorrespondent static cast? Pavel C++ 7 09-18-2010 11:35 PM
simulation result is correct but synthesis result is not correct J.Ram VHDL 7 12-03-2008 01:26 PM
1. Ruby result: 101 seconds , 2. Java result:9.8 seconds, 3. Perl result:62 seconds Michael Tan Ruby 32 07-21-2005 03:23 PM



Advertisments