Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluation order of chaining function call inconsistent #800

Closed
gopherbot opened this issue May 23, 2010 · 3 comments
Closed

Evaluation order of chaining function call inconsistent #800

gopherbot opened this issue May 23, 2010 · 3 comments

Comments

@gopherbot
Copy link

by emiel.mols:

What steps will reproduce the problem?
Two test cases which evaluate differently can be found here
<http://gist.github.com/410574>;. I 
use 8g version 5440.

What is the expected output? What do you see instead?
The compiler to generate code that either first evaluates all expressions in the chained 
arguments, or code that evaluates the chain from left-to-right. Either way, not to do it 
differently. 

What is your $GOOS?  $GOARCH?
darwin; 386

Which revision are you using?  (hg identify)
17ded5ad443b tip

Please provide any additional information below.
Relevant assembly is also attached. Line 27 clearly starts with invoking s.Len(), while
line 33 
begins with s.Clear().

Btw, I might imagine that this is just 'the way things work' with the len(...)
expression probably 
just being a pointer to the slice's length field or something, but still, from an
implementing view it 
took me half the night to figure out what the hell was going on.
@rsc
Copy link
Contributor

rsc commented May 23, 2010

Comment 1:

Thanks for the test case.
The spec is quite clear that in
s.Clear().Push(byte(s.Len()))
the s.Clear() must run before s.Len().
The same is true of
s.Clear().Push(byte(len(s.a)))
This is a bug in 8g and probably 5g and 6g too.

Labels changed: added compilerbug.

Owner changed to r...@golang.org.

Status changed to Accepted.

@gopherbot
Copy link
Author

Comment 2 by emiel.mols:

Alright, nice to see it is just an implementation-thing ;).
Although I initially expected the bug to be dependent on one of the quirks of my
original implementation, this 
appeared to be an incorrect assumption. I have therefore cleaned up the test case (at
the same gist), and 
confirmed that it indeed also goes wrong when using darwin/6g.

@rsc
Copy link
Contributor

rsc commented Jul 15, 2010

Comment 3:

This issue was closed by revision 4c0de30.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants