go tip (go1.7 and many before)

in runtime/string.go there is a maxstrings variable that starts with a value of 256 and is updated whenever rawstring is called.

This limit can be expanded by concatenating any strings.

However it is not consistent with what the length of the longest go string really is:

https://play.golang.org/p/BUY9zhs7pT

package main

func main() {
    s := "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"+
         "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"+
         "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"+
         "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"
    _ = s+" "
    print(s)
}

e.g. defining a string constant that is longer than the starting maxstring value will not print.

when updating the maxstring length by e.g. adding the string with " " (or adding any other strings where the concatination is longer than orginal s) the above program prints the string fine.

Since gwrite later just truncates the string in a copy if it does not fit into the g.writebuf there seems no risk of out of bounds write. Since the limit can just be pushed upwards by arbitrary string concatenations there seems also to be no protection against the string output being cut off early depending on g.writebuf capacity.

Removing maxstring and running ./all.bash did not reveal any immediate problems.
( apart from an explicit test that maxstring is updated by gostringnocopy which would be obsolete once maxstring is removed )

rsc "I don't see that it's causing any harm, and it's still useful.":
https://groups.google.com/forum/#!msg/golang-dev/J2OiPumlwuc/neEqKcCWyf8J

however that seems to be from a time where runtime was not written in go and we did not have extra updates to maxstrings in e.g. gostringnocopy #8706 .

Would it be ok to remove maxstrings in runtime and maxstring updates from runtime/strings.go nowadays?

If not should cases were this protection against broken go string lengths is overprotecting be fixed (e.g. similar to /go/issues/8706) ?

/cc @josharian @randall77