Not possible in Go, the runtime will panic.
> there's still a hell of a lot of C code out there with array overflow errors
An extremely easy error to make in many cases, which is why modern programming languages bounds-check.
> Exception stack traces
Go will give you a very nice stacktrace should it ever panic.
> I have no experience with Go
Which is really the problem. People keep arguing about Go's merits based on no substantive understanding.
It's very obvious which operations can fail without a panic in Go, because functions explicitly return error objects -- actual error objects, not magic numbers. The return signature for the Go equivalent of fread is (int, error), not (int).
They are not arguing, they are asking questions to improve their understanding.
The context of the thread, however, very much is people arguing. See for example graue's post a few levels up.
Is -B for disabling bounds checking no longer supported?
Looking at the code it seems it has been removed.
> ... I would certainly never enable such a thing in real code.
So I assume you don't do C or C++. :)
While I agree with you, there are certain cases where it might help. That is why most strong typed languages with native compilers allow to selectively disable bounds checking, since the Pascal/Modula-2 days.
I only support doing this if profiling proves it is really worth it, give the security issues.
package main
func main() {
slice := []string{"first", "second", "third"}
println(slice[1])
slice = slice[0:2]
println(slice[2])
}
go build -gcflags -B wat.go
./wat
second
third
Next time I better checkout and do a proper grep.
If C had a simple universal switch for bounds checking, I'd turn it on everywhere and immediately revoke commit privileges for anyone on my team who turned it back off. But it doesn't, and necessarily can't, making your statement nothing more than an annoying exercise in wrongful pedantry. It is contextually obvious I was talking about Go code and/or languages/compilers with such a switch.
go tool 6g -help
go build -gcflags '-B'
Sure - and the possibility of exceeding the bounds of an array would be a clue that you need to bounds check, but there's still a hell of a lot of C code out there with array overflow errors. You can argue that people who make these errors are bad programmers, but that's fairly irrelevant - most programmers of any level will end up working with code with errors in it at some point. Exception stack traces are an extremely useful way to find out where something went wrong when someone failed to do some necessary error checking.
I have no experience with Go, so I'm not saying what it does is wrong - I'm just curious. Say a customer experiences a failure with your software caused by some missing/incorrect error handling, what do you do to work out what happened?