modifying a variable twice in a statement (comparison to c)

Discussion in 'Perl Misc' started by Ivan Novick, Feb 4, 2007.

  1. Ivan Novick

    Ivan Novick Guest

    Hi,

    In C, you are not allowed to modify a variable 2 times in one
    statement.

    In perl, this code does not complain at all (similar code in C is
    illegal).

    Can someone varify that this is legal perl syntax?

    ####################################
    #!/usr/bin/perl
    use strict;
    use warnings;

    my $test = 1;

    $test = ++$test;

    print "$test\n";
    ####################################

    Thanks,
    Ivan
    http://www.0x4849.net
     
    Ivan Novick, Feb 4, 2007
    #1
    1. Advertisements

  2. Ivan Novick

    Ivan Novick Guest

    Not sure what the result should be, in C it is undefined, that is why
    I am asking this question.
    Obviously the problem can be solved by changing the code, my question
    is about how perl works, not how to solve some specific problem.
     
    Ivan Novick, Feb 4, 2007
    #2
    1. Advertisements

  3. IN> Obviously the problem can be solved by changing the code, my
    IN> question is about how perl works, not how to solve some
    IN> specific problem.

    The C answer is to consult the Standard.

    The Perl answer is the same, except that we don't have a Standard, we
    have a reference implementation. Try it and see.

    And if you want to be sure how it works, look for what the perldocs
    say. If the perldocs don't say anything on the matter, there's no
    guarantee it will continue to work that way.

    Charlton
     
    Charlton Wilbur, Feb 4, 2007
    #3
  4. Ivan Novick

    Dave Slayton Guest


    Why stop there? Even more fun is available!:

    $wheeeee = 5;
    $wheeeee = ++($wheeeee = ++($wheeeee = ++$wheeeee));

    etc.

    :)
     
    Dave Slayton, Feb 4, 2007
    #4
  5. Is it? I thought it was just that it's semantics were undefined.
    Yes it's perfectly legal _syntax_.
    Semnatically it's is probably best considered ambiguous.
     
    Brian McCauley, Feb 4, 2007
    #5
  6. Which is the same thing as "illegal" in C. "Undefined behaviour" means
    absolutely anything can happen. The compiler may produce some code which
    conforms to some people's expectations of what that code should do. It
    may produce code which crashes and/or formats the hard disk. It may
    abort compilation with an error message. It may send rude emails to your
    boss.

    hp
     
    Peter J. Holzer, Feb 4, 2007
    #6
  7. Ivan Novick

    Uri Guttman Guest

    PJH> It may send rude emails to your boss.

    i know i used a c compiler which did that when i double modified a
    variable. could have been an early gcc.

    uri
     
    Uri Guttman, Feb 4, 2007
    #7
  8. Small point, but in C you *can* modify a variable multiple times in
    one statement. You are not allowed to do that between sequence points
    (and a statement end is one place you get a sequence point) but you
    can, legally, write:

    (x = 1) && ++x;

    because && gives you another one.

    As has been said, the perldocs refer to multiple modification in one
    statement so Perl seems to have adopted a simpler restriction.
     
    Ben Bacarisse, Feb 5, 2007
    #8
  9. Ivan Novick

    Ivan Novick Guest

    I would have expected perl to either reject the syntax or accept as
    valid.

    In C just because it compiles and runs does not mean it conforms to
    the standard, but since in Perl the implementation is the standard, it
    makes things tricky when certain things that seem to work in the
    reference implementation are actually undefined.

    I guess perldoc is like a mini language standard, and if its not in
    perldoc then you go by what Perl actually does.

    Ivan Novick
    http://www.0x4849.net
     
    Ivan Novick, Feb 5, 2007
    #9
  10. Obviously perl accepts the syntax as valid or do you get a syntax error?
    You are confusing syntax and semantic.

    jue
     
    Jürgen Exner, Feb 5, 2007
    #10
  11. Ivan Novick

    Uri Guttman Guest

    IN> I would have expected perl to either reject the syntax or accept as
    IN> valid.

    you can't reject the syntax because it is legal syntax. perl accepts it
    as valid it is just bad code from a semantic point of view. why do you
    keep harping on this? it is also documented to be an undefined situation
    as someone quoted the docs on it.

    IN> In C just because it compiles and runs does not mean it conforms to
    IN> the standard, but since in Perl the implementation is the standard, it
    IN> makes things tricky when certain things that seem to work in the
    IN> reference implementation are actually undefined.

    the perl docs are very good and accurate. did you read the quoted part
    which covers this? what about it don't you understand?

    IN> I guess perldoc is like a mini language standard, and if its not in
    IN> perldoc then you go by what Perl actually does.

    that may be true but the difference between what the docs say and what
    perl does is very small. and if you have a legitimate discrepency then
    report it to p5p. double modification is not one of those and why do you
    care so much about it as it is bad coding in all languages (except for
    the few that specify behavior for it).

    uri
     
    Uri Guttman, Feb 5, 2007
    #11
  12. UG> and why do you care so much about it as it is bad coding in
    UG> all languages (except for the few that specify behavior for
    UG> it).

    I'd say it's bad coding in general, on the principle that code is
    supposed to communicate clearly to the maintainer. Any expression in
    which a variable is accessed or modified more than once can be
    rewritten so as to express the intent of the programmer clearly and
    unambiguously.

    Perl golf is another matter entirely; there, all bets are off.

    Charlton
     
    Charlton Wilbur, Feb 5, 2007
    #12
  13. That's not a syntax error, that's a constraint violation. Syntactically,
    'x ++ ++' is a valid postfix-expression:

    postfix-expression: postfix-expression ++
    postfix-expression: postfix-expression ++ ++
    postfix-expression: primary-expression ++ ++
    postfix-expression: identifier ++ ++
    postfix-expression: x ++ ++

    However, it violates the constraint, that the operand of ++ must be an
    lvalue. x++ isn't an lvalue, so x++ ++ violates this constraint.
    Then you didn't try any C-compiler conforming to ISO-9899-1990. A
    constraint violation must be diagnosed.
    That's an interesting result. From looking at the assembler output, the
    Compiler obviously does something like this:

    "x++"? Ok, that means to take the current value of x, and increment x
    later, so transform "x = x++ + ++x" into "x = x + ++x, x = x + 1;"

    "++x"? Ok, that means increment x now, and use the new value. So we
    transform "x = x + ++x, x = x + 1;" into
    "x = x + 1, x = x + x, x = x + 1"

    Nice.

    hp
     
    Peter J. Holzer, Feb 5, 2007
    #13
  14. Ivan Novick

    Mirco Wahab Guest

    int x; pushl %ebp
    movl %esp, %ebp
    subl $36, %esp

    x = 1; movl $1, -8(%ebp) # WRITE 1 into [stack] (location for x)

    x = x++ + ++x; addl $1, -8(%ebp) # ADD 1 to [stack] (now 2)
    movl -8(%ebp), %eax # WRITE [stack] into [register] (copy 2)
    addl %eax, -8(%ebp) # ADD [register] to [stack] (now 4)
    addl $1, -8(%ebp) # ADD 1 to [stack] (now 5)



    Regards

    M.
     
    Mirco Wahab, Feb 6, 2007
    #14
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.