4 ms·
Author here. I agree that this could cause surprises. Are there specific cases you have in mind? Two cases I have thought of are stack traces and logging that
by jschlatter 11y ago
Author here. I agree that this could cause surprises. Are there specific cases you have in mind?
Two cases I have thought of are stack traces and logging that inspects the stack. In the former case, if you get a stack trace while debugging it will not mean much because the lines do not match those of your code. In the latter case, logging statements may print the wrong things if they depend on being called a certain number of stack frames below user code. glog does this, for example[1]. I don't have solutions to either case yet, but I have some ideas of how to start. I think the utility the tool provides is well worth those two issues, and I'm hopeful that both can be fixed.
[1] https://github.com/golang/glog/blob/master/glog.go#L536 https://github.com/golang/glog/blob/master/glog.go#L536
- deleted 11y ago[deleted]
- jschlatter 11y ago> Another is that you may inadvertently corrupt or change the behavior of the code in an unintentional way if you modify it incorrectly I'm concerned about this, too. One of my next high priorities for godebug is to download many open source projects and search for behavior differences caused by the debugger. I would also like to generate new programs and test them as well. > But, you get the easy 80% with this for sure. I'm just prodding you to work on the other 20%. I will. I'm excited about the project and want to make it as useful as I can.
- andrewchambers 11y agoA compiler transforms source code. It doesn't have access to all programs either, yet we trust them most of the time.
- skybrian 11y agoA neat trick in some languages is to modify the source so that the line numbers don't change, for example by using semicolons instead of newlines and making sure a newline never appears in inserted instrumentation code. But I'm not sure if that's possible in Go.