On 1/20/21 12:27 PM, Axel Wagner wrote: > > Language design is a trade-off and there is no such thing as a perfect > type-system. Go has decided that it doesn't want to occupy the "most > type-safety > possible" spot in the language design space. > > I don't think it is true that anyone is "downplaying" any type-safety issues > of > nil-pointers and the like.
It has been stated in a thread that there have never been any type safety related security issues. Type safety often helps avoid input validation errors, though it can and should be done manually too. > > Is this not a type safety issue? > > "https://www.cvedetails.com/cve/CVE-2019-14809/ > <https://www.cvedetails.com/cve/CVE-2019-14809/>" > > > I'm not entirely certain, but I don't think so. AIUI the main issue you are > attributing to a type-safety problem is that (*net.URL).Port() used to return > non-numeric ports on malformed URLs. But that's a library issue, not an issue > with the language type-system - `int` is a supported type and it would have > prevented this. A Haskell library that returns a String could have exactly the > same issue, even though the Haskell type system is significantly more powerful > than Go's. > Right, but had a typed function been used that took a port as an int and did validation early. Especially with the single task principle in mind. This would never have happened. Actually in this case either for performance or maybe because strconv couldn't be used to produce an error. It was handled as a function that takes a string and checks for characters 0-9. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/79f1477f-70ff-bf71-b13e-e7e3d40f7857%40gmail.com.
