4 ms·

You can do this with any language with a type system by wrapping reads with a 'Tainted' type. ie: fn safe_read(path: str) -> Tainted<IO> { Tainted(unsafe_re

You can do this with any language with a type system by wrapping reads with a 'Tainted' type. ie: fn safe_read(path: str) -> Tainted<IO> { Tainted(unsafe_read(path)) } And then you can apply functions to Tainted<IO> or whatever type that convert it into something structured / validated. So long as your functions only take in those validated types (ie: you do not write functions that take str) you can ensure that new reads will fail to typcheck without first parsing. To be honest this is how most programs I see work anyways, at least in typed languages. Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already.

marcosdumay 6y ago
You can do some actually useful stuff with a real type system, instead of replicating Perl's stupidity. For example, you can convert the input into a safe representation, suitable for the exact place you'll be using the string, instead of "validating" it.
- masklinn 6y ago
  Exactly. What you need is not a “tainted” type and assume everything that’s not it is safe. That’s not the case. Html-escaping a string does not make it safe for SQL or whatever. What you need is a safe type for each use case, and ways to convert values to that (or mark them as that depending on your TS).
- staticassertion 6y ago
  This is what I was referring to at the end of my post: > Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already. ie: Most programs in typed languages already do what you're saying - they parse the data directly into a structure, and therefor they validate some aspects of it naturally, so even when you do see a 'str' in typed code it's very often already gone through some sort of parsing phase.
  - marcosdumay 6y ago
    Hum... Your sibling has a nice explanation of what I was trying to say. You don't sanitize user input when parsing, you do it on usage. "Robert'; drop table users--" is a perfectly fine name and you shouldn't mangle it on you data fields.
    - staticassertion 6y ago
      We're saying the same thing.

marcosdumay 6y ago

You can do some actually useful stuff with a real type system, instead of replicating Perl's stupidity. For example, you can convert the input into a safe representation, suitable for the exact place you'll be using the string, instead of "validating" it.

masklinn 6y ago
Exactly. What you need is not a “tainted” type and assume everything that’s not it is safe. That’s not the case. Html-escaping a string does not make it safe for SQL or whatever. What you need is a safe type for each use case, and ways to convert values to that (or mark them as that depending on your TS).
staticassertion 6y ago
This is what I was referring to at the end of my post: > Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already. ie: Most programs in typed languages already do what you're saying - they parse the data directly into a structure, and therefor they validate some aspects of it naturally, so even when you do see a 'str' in typed code it's very often already gone through some sort of parsing phase.
- marcosdumay 6y ago
  Hum... Your sibling has a nice explanation of what I was trying to say. You don't sanitize user input when parsing, you do it on usage. "Robert'; drop table users--" is a perfectly fine name and you shouldn't mangle it on you data fields.
  - staticassertion 6y ago
    We're saying the same thing.