This had to do with XSS-proofing templates, which is a bit different and requires compile time magic. I've seen people concatenate strings while using prepared PDO queries in PHP -- nonnegotiable safety built in to the library is much better. This can't be handled with a type system.
-Manish Goregaokar On Mon, Sep 22, 2014 at 10:10 PM, Matthieu Monrocq < [email protected]> wrote: > It's completely unnecessary actually. > > If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref<String> and would be > built from a String by a method performing the necessary escaping. > > If a method requires a SQL-safe string... ah no, don't do that, use > bind-parameters and you are guaranteed to be sql-injection safe. > > In each case, the attributes so defined can be perfectly replaced with > appropriate types... so why not use types ? > > > > On Mon, Sep 22, 2014 at 4:50 AM, Manish Goregaokar <[email protected]> > wrote: > >> >> That's not how Rust defines `unsafe`. It's open to misuse, and the >>> compiler will happily point out that it's not being used correctly via >>> the unnecessary unsafe lint. >>> >> >> If that's the case, do you think there's some worth in allowing the >> programmer to define arbitrary generic safety types? >> >> E.g have an `#[unsafe(strings)]` attribute that can be placed on methods >> that break String guarantees (and placed on blocks where we wish to allow >> such calls). `#[unsafe(sql)]` for SQL methods that are injection-prone. If >> something like this slide >> <https://www.youtube.com/watch?feature=player_detailpage&v=jVoFws7rp88#t=1664> >> was ever implemented, methods that allow unsafe (XSS-prone) vulnerabilities >> can have `#[unsafe(xss)]`. >> >> Rust does a bunch of compile time checking to achieve memory safety. It >> also provides a syntax extension/lint system that allows for programmers to >> define further compile time checks, which open up the gate for many more >> possible safety guarantees (instead of relying on separate static analysis >> tools), and not just memory safety. Perhaps we should start recognizing and >> leveraging that ability more :) >> >> -Manish Goregaokar >> >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
