Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^5: Why does the first $c evaluate to the incremented value ... (bug)

by oiskuu (Hermit)
on Mar 05, 2014 at 19:31 UTC ( #1077144=note: print w/replies, xml ) Need Help??

in reply to Re^4: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? ("undefined")
in thread Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?

Ok, engaging lawyer mode. ISO C99 standard says, in 6.5 (2):

Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
Failing the above rule, behavior is undefined. However, regarding initializer lists, read this, this question, and this this report. Various C and C++ standards differ in their wording, and guarantees they make. Coming back to C99, 6.7.8 (19) says:
The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; ...
But then, 6.7.8 (23)
The order in which any side effects occur among the initialization list expressions is unspecified.

This example code is valid in C99 (no undefined behaviour), yet what it prints is unspecified.

#include <stdio.h> void meh(int t[]) { int i = 0; int foo[] = { [1] = ++i, [2] = ++i, [0] = ++i }; for (i = 0; i < 3; i++) { t[i] = foo[i]; } } int main(void) { int x[3]; meh(x); printf("%d %d %d\n", x[0], x[1], x[2]); }

For perl, flexibility in constructing and manipulating lists, e.g. using iterators (with their side effects) and so on, is essential quality of the language. There is no undefined behavior here. This thing quacks like a bug, it is a bug. How much speed-up do you think this buggy optimization is worth?

  • Comment on Re^5: Why does the first $c evaluate to the incremented value ... (bug)
  • Download Code

Replies are listed 'Best First'.
Re^6: Why does the first $c evaluate to the incremented value ... (hahaha)
by tye (Sage) on Mar 05, 2014 at 20:09 UTC

    Perl does indeed value giving the programmer flexibility in how to write things. That means you are allowed to write things stupidly. When you do, you suffer.

    How much speed-up do you think this buggy optimization is worth?

    Who declared that this was due to an optimization? It is as likely to be due to a simplification. If you think tying the hands of the implementers is a trivial concern, then you should probably go try to be an implementer of Perl's C code at this point. Go fix this "bug" in the Perl source code. If you don't succeed, at least you might get a much better appreciation for the trade-offs involved in trying to make stupid constructs behave predictably (in the eyes of their too-clever authors).

    As to your "lawyer mode", you have jumped to conclusions about how precisely the "don't modify something twice in the same expression" taboo is the same in Perl as in C. Note that I didn't admonish you to not modify something twice in the same expression. Also note that I didn't say anything about "sequence points". I said you should not use a variable in the same statement where you have modified it.

    Perl has aliases and whether you get an alias or a copy can be subject to rather subtle factors, arcane implementation details, and (indeed) optimizations. C doesn't have this feature and so C rules don't address it. So simple order of operations is not the only gotcha when writing Perl code. And yet, I don't find it difficult at all to avoid separately using something in the same statement where I've modified it.

    I don't really know how much slower the average Perl code would run if a whole class of uses of a bare variable where forced to make a copy of the variable's value just in case somebody got way too clever and decided to modify the variable in that same statement. It might be a bigger performance hit than you seem to expect.

    But even if you went and implemented that, you'd likely just get burned later by complaints about how you "broke" some other clever code that was relying on the fact that the value was changing because it wasn't a copy.

    Working on Perl's C code is complex enough already. We don't need to make it that much worse via misguided attempts to "define" the behavior of stupidly ambiguous constructs.

    - tye        

      My "lawyer mode" rant was to show that C is playing catch-up in some areas, and that the rules are anything but clear-cut.

      I wouldn't consider perl code that the OP wrote, stupid. In fact I might quite possibly have used the same construct...

        Then you simply need to update your best practices to include "Using a variable in the same statement as you separately modify it is stupid".

        (Then, when it breaks [as it did] you'll save a lot of time by not trying to convince people that it is a bug. :)

        - tye        

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1077144]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2018-05-28 02:26 GMT
Find Nodes?
    Voting Booth?