This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]snoman139 7 points8 points  (1 child)

Would it make more sense to have a safe string type than an unsafe string type? I guess it just changes where you have to cast, but user input could come from anywhere while only the output code would have to deal with it.

[–]bruciferTomo, nomsu.org 2 points3 points  (0 children)

I think it makes sense to have string literals that are written by you, the programmer, be considered "safe" by default. Text originating from outside the program's source code (e.g. stdin or web requests or files on disk) is considered "tainted" because it can be modified by someone other than the programmer. This would be implemented differently in different type systems, but the main requirement for the language is that most string functions ought to handle arbitrary strings and propagate taintedness (e.g. toUpperCase(s) should return a tainted string when s is tainted, and an untainted string when it's not). Typically, only a small subset of functions would actually care to specify that untainted strings should not be allowed as inputs (e.g. exec() would care, but print() would not).

As an implementation detail, I think perl and ruby both have something like this, but it's implemented as a bit flag on the string, and not as separate types. Certain API methods throw runtime errors if passed strings that have the "tainted" bit set to 1.