[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Michael Press

3/18/2011 9:53:00 PM

int main(void)
{
---3;
return 0;
}

error: invalid lvalue in decrement

???
Why does this have to be an error?
The value could be -4 or -3 or -2.
If somebody [shuffles feet] wants
to use this construction, then who
would stop him?

--
Michael Press
47 Answers

Lew Pitcher

3/18/2011 9:59:00 PM

0

On March 18, 2011 17:53, in comp.lang.c, rubrum@pacbell.net wrote:

> int main(void)
> {
> ---3;
> return 0;
> }
>
> error: invalid lvalue in decrement
>
> ???
> Why does this have to be an error?

Because you can't pre-decrement a constant?

Read
---3
as either
- --3
or
-- -3
and remember what pre-decrement does.

> The value could be -4 or -3 or -2.

Not really.

The symantics of pre-decrement require that the decremented value be stored
somewhere; where should the compiler/runtime store /this/ pre-decremented
value?

> If somebody [shuffles feet] wants
> to use this construction, then who
> would stop him?

Apparently, the compiler (or the compiler-writer). Presumably, with support
from the ISO C committee (by way of the ISO C standard).


--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfr... | Just Linux: http://jus...
---------- Slackware - Because I know what I'm doing. ------


Sjouke Burry

3/18/2011 11:25:00 PM

0

Michael Press wrote:
> int main(void)
> {
> ---3;
> return 0;
> }
>
> error: invalid lvalue in decrement
>
> ???
> Why does this have to be an error?
> The value could be -4 or -3 or -2.
> If somebody [shuffles feet] wants
> to use this construction, then who
> would stop him?
>
Any sensibly designed compiler?

Or a boss firing a programmer who likes to put stupid things
in his software?

Keith Thompson

3/19/2011 12:57:00 AM

0

Lew Pitcher <lpitcher@teksavvy.com> writes:
> On March 18, 2011 17:53, in comp.lang.c, rubrum@pacbell.net wrote:
>> int main(void)
>> {
>> ---3;
>> return 0;
>> }
>>
>> error: invalid lvalue in decrement
>>
>> ???
>> Why does this have to be an error?
>
> Because you can't pre-decrement a constant?
>
> Read
> ---3
> as either
> - --3
> or
> -- -3
> and remember what pre-decrement does.

The correct reading is
-- -3
due to the "maximal munch" rule. This is the same reason that
x-----x
is a syntax error, rather than being tokenized as
x -- - -- x

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

3/19/2011 1:15:00 AM

0

Michael Press <rubrum@pacbell.net> writes:
> int main(void)
> {
> ---3;
> return 0;
> }
>
> error: invalid lvalue in decrement
>
> ???
> Why does this have to be an error?
> The value could be -4 or -3 or -2.
> If somebody [shuffles feet] wants
> to use this construction, then who
> would stop him?

Apart from the fact that "---3;" is a constraint violation, and
that every conforming compiler must issue a diagnostic for it, and
in practice I suspect that every existing compiler will reject it:

Whatever you intended "---3" to mean, there is certainly a
clearer way to express that meaning. For the most nearly sensible
interpretation, just write either "-3 - 1" or "-4". Or, since
you're discarding the result, just delete that line of code.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Michael Press

3/19/2011 6:30:00 PM

0

In article <ln1v23gbbw.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> > int main(void)
> > {
> > ---3;
> > return 0;
> > }
> >
> > error: invalid lvalue in decrement
> >
> > ???
> > Why does this have to be an error?
> > The value could be -4 or -3 or -2.
> > If somebody [shuffles feet] wants
> > to use this construction, then who
> > would stop him?
>
> Apart from the fact that "---3;" is a constraint violation, and
> that every conforming compiler must issue a diagnostic for it, and
> in practice I suspect that every existing compiler will reject it:
>
> Whatever you intended "---3" to mean, there is certainly a
> clearer way to express that meaning. For the most nearly sensible
> interpretation, just write either "-3 - 1" or "-4". Or, since
> you're discarding the result, just delete that line of code.

First, I am brain dead for writing ---3,
and acting as if 3 can be decremented.

Second, it can be parsed as (-(-(-(3)))),
but is not.

Third

int main(void)
{
int x = 3;

---x;

return 0;
}

gets the same error.
In function 'main':
error: invalid lvalue in decrement

A warning is well deserved.
---x can be parsed into
something meaningful in C.

--
Michael Press

Ben Bacarisse

3/19/2011 7:28:00 PM

0

Michael Press <rubrum@pacbell.net> writes:
<snip>
> A warning is well deserved.
> ---x can be parsed into
> something meaningful in C.

Did you mean "can't" rather than "can"? The rules of C permit only one
parse (which is --(-x)). A compiler that came up with any other parse
is not a C compiler.

--
Ben.

Michael Press

3/19/2011 11:07:00 PM

0

In article
<0.f132f5aaec90d95e2189.20110319192736GMT.871v22x653.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> <snip>
> > A warning is well deserved.
> > ---x can be parsed into
> > something meaningful in C.
>
> Did you mean "can't" rather than "can"? The rules of C permit only one
> parse (which is --(-x)). A compiler that came up with any other parse
> is not a C compiler.

Yes, I do not speak ex cathedra.

The question remains why

---x;

precipitates an error.

--
Michael Press

jt

3/19/2011 11:44:00 PM

0

Michael Press <rubrum@pacbell.net> wrote:
> In article
> <0.f132f5aaec90d95e2189.20110319192736GMT.871v22x653.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > Michael Press <rubrum@pacbell.net> writes:
> > <snip>
> > > A warning is well deserved.
> > > ---x can be parsed into
> > > something meaningful in C.
> >
> > Did you mean "can't" rather than "can"? The rules of C permit only one
> > parse (which is --(-x)). A compiler that came up with any other parse
> > is not a C compiler.

> Yes, I do not speak ex cathedra.

> The question remains why

> ---x;

> precipitates an error.

Because, as it has been pointed out in this thread e.g. by
Keith Thompson, it's parsed as

-- ( -x );

and '-x' is the *number* one gets when taking the negative of
what's stored in the variable 'x'. But a value can't be decre-
mented, only a variable can. So it's akin to '---3'. If you want

- ( --x );

(i.e. decrement what's stored in 'x' and, as a result of the ex-
pression, get the negative of the resulting value, i.e. what's
stored in 'x' after the decrement) then you have to write it that
way. What you want with that is a different question, of course,
since it doesn't make much sense because the resulting value will
be thrown away.

If you're just assembling random tokens to see what happens you
shouldn't be too surprised that some combinations don't make any
sense, there's no language (computer or human) where all possible
combinations of tokens are meaningful - normally only a small
subset of all possible combinations is syntactically correct:

* Is brown dog the.
The dog is brown.
* Brown dog the is.
* The brown dog is.
Brown is the dog.
* Is brown the dog.
....

Some of those sentences make sense, some don't (at least for a
"standard english speaker"). Same for C, some combinations of
tokens don't make sense. And e.g. '---3' isn't correct nor is
'---x'. The difference to a human language is that the rules
of what's correct are clearly defined and can be looked up in
the standard for the C language. That's what C compiler writers
have to care for, not random assemblies of tokens.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://t...

Ben Bacarisse

3/19/2011 11:54:00 PM

0

Michael Press <rubrum@pacbell.net> writes:

> In article
> <0.f132f5aaec90d95e2189.20110319192736GMT.871v22x653.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Michael Press <rubrum@pacbell.net> writes:
>> <snip>
>> > A warning is well deserved.
>> > ---x can be parsed into
>> > something meaningful in C.
>>
>> Did you mean "can't" rather than "can"? The rules of C permit only one
>> parse (which is --(-x)). A compiler that came up with any other parse
>> is not a C compiler.
>
> Yes, I do not speak ex cathedra.
>
> The question remains why
>
> ---x;
>
> precipitates an error.

I thought this has come up already. The input broken is up into tokens
using the rules that the next preprocessing token is "the longest
sequence of characters that could constitute a preprocessing token" (6.4
p4). Thus your statements is broken up into four tokens:

<--> <-> <x> <;>

The parser must then "fit" this sequence to the grammar rules. It will
conclude that we have a statement. In particular an expression followed
by a semicolon. The expression is a unary expression whose operand is
another unary expression. The operand of that inner unary expression is
an identifier, 'x'.

The result (--(-x)) is a constraint violation for the same reason ---3
is one: -x is not a "modifiable lvalue". In fact it is not a lvalue at
all let along a modifiable one.

This may be too much or to little explanation. If so, I'm sorry. I am
not 100% clear what part was not already covered.

--
Ben.

Michael Press

3/21/2011 3:30:00 AM

0

In article
<0.e2102587e2eaccedc927.20110319235358GMT.87sjuivf8p.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Michael Press <rubrum@pacbell.net> writes:
>
> > In article
> > <0.f132f5aaec90d95e2189.20110319192736GMT.871v22x653.fsf@bsb.me.uk>,
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >
> >> Michael Press <rubrum@pacbell.net> writes:
> >> <snip>
> >> > A warning is well deserved.
> >> > ---x can be parsed into
> >> > something meaningful in C.
> >>
> >> Did you mean "can't" rather than "can"? The rules of C permit only one
> >> parse (which is --(-x)). A compiler that came up with any other parse
> >> is not a C compiler.
> >
> > Yes, I do not speak ex cathedra.
> >
> > The question remains why
> >
> > ---x;
> >
> > precipitates an error.
>
> I thought this has come up already. The input broken is up into tokens
> using the rules that the next preprocessing token is "the longest
> sequence of characters that could constitute a preprocessing token" (6.4
> p4). Thus your statements is broken up into four tokens:
>
> <--> <-> <x> <;>

Unary minus and pre-decrement associate right to left,
so a maximum valid string length tokenizer would give

(-(--(x)))

No?

If ---x could be parsed meaningfully, then it should.

--
Michael Press