It seems natural to conflate memory (to which unsafe refers to uses
of) and types.
It might make sense to extend the terminology to types: perhaps
bottom could express a similar thing: that beyond which the compiler
is uncertain.
However, if we tried to extend this terminology directly into
It's completely unnecessary actually.
If a method requires a XSS-safe string, then it should take the
XssSafeString parameter, which would implement DerefString 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
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
On Mon, Sep 22, 2014 at 9:40 AM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
If a method requires a XSS-safe string, then it should take the
XssSafeString parameter, which would implement DerefString and would be
built from a String by a method performing the necessary escaping.
This
On 22/09/14 03:21 PM, Chris Morgan wrote:
It's completely unnecessary actually.
Would that it were. There was a time when I believed it was, but it's not.
If a method requires a XSS-safe string, then it should take the
XssSafeString parameter, which would implement DerefString and would
be
On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay danielmi...@gmail.com
wrote:
Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It
uses `unsafe` as a memory safety boundary, and in this case breaking the
invariant would be memory unsafe.
I just want to say that I completely
On 22/09/14 05:12 PM, Tony Arcieri wrote:
On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It
uses `unsafe` as a memory safety boundary, and in this case
On Mon, Sep 22, 2014 at 2:15 PM, Daniel Micay danielmi...@gmail.com wrote:
I think it can be solved by using visibility, along with providing a way
to override the visibility rules and call private functions. That means
replacing the current usage of visibility for memory safety with unsafe
As Chris mentioned, it's not about using the type system to create safety.
We're assuming that exists, the idea is to gate unchecked access to the
data (which *is* required for libraries created for generic use) with the
`unsafe` keyword. However, many seem to be of the opinion that `unsafe` is
On Mon, Sep 22, 2014 at 3:45 PM, Manish Goregaokar manishsm...@gmail.com
wrote:
As Chris mentioned, it's not about using the type system to create safety.
We're assuming that exists
The sort of safety I'm describing does not exist in Rust whatsoever AFAIK.
The very specific approach I'm
On 22/09/14 06:45 PM, Manish Goregaokar wrote:
As Chris mentioned, it's not about using the type system to create
safety. We're assuming that exists, the idea is to gate unchecked access
to the data (which /is/ required for libraries created for generic use)
with the `unsafe` keyword. However,
I'm not talking about unsafe fields. (maybe I gave that impression? Sorry.)
That's how it is defined in the manual, sure, but the language is changing
:) Anyway, as mentioned before we don't need to use `unsafe` for non-memory
safety guarantees, if we define anothe attribute that genericises it.
On 21/09/14 02:29 AM, Tony Arcieri wrote:
Traditionally in Rust, unsafe has centered around memory safety. The
reference manual describes it as such:
http://doc.rust-lang.org/rust.html#unsafety
At Strange Loop, during Chris Morgan's talk, someone asked about using
the type system to
On Sun, Sep 21, 2014 at 1:34 AM, Daniel Micay danielmi...@gmail.com wrote:
It's not possible to represent the semantics of 'insecure' in the
language as
that's very poorly defined and varies across domains and libraries.
I'd define it as think before you use this
--
Tony Arcieri
Also, here's a paper that provides a formalized definition of security
domains using dependent types:
https://research.microsoft.com/en-us/um/people/nswamy/papers/gradual-typing-embedded-securely-in-javascript-draft.pdf
Would love to see Rust get dependent types eventually... but hey, I get it,
On Sep 20, 2014, at 11:29 PM, Tony Arcieri basc...@gmail.com wrote:
He suggested using unsafe to call out when a SQL query is being made with a
raw string.
On the one hand I really liked the clarity of calling out passing a raw
string to a SQL driver as being inherently unsafe, but on the
On Sun, Sep 21, 2014 at 2:02 AM, Cameron Zwarich zwar...@mozilla.com
wrote:
The usual solution to this particular problem in typed languages is to
make a new type wrapping sanitized strings, use some feature of the
language (e.g. abstract types or module privacy) to restrict the creation
of
On 21/09/14 07:34, Daniel Micay wrote:
It's not intended to be used for anything other than memory safety.
It’s also used to maintain invariants, such as the bytes inside a String
being valid UTF-8: String::push_bytes() is unsafe, but
String::push_str() is not.
--
Simon Sapin
On 21/09/14 05:57 AM, Simon Sapin wrote:
On 21/09/14 07:34, Daniel Micay wrote:
It's not intended to be used for anything other than memory safety.
It’s also used to maintain invariants, such as the bytes inside a String
being valid UTF-8: String::push_bytes() is unsafe, but
Personally, I feel safety generalizes pretty well to any concept
that should be called out explicitly as unsafe--not just memory
safety.
On Sun, Sep 21, 2014 at 4:12 PM, Daniel Micay danielmi...@gmail.com wrote:
On 21/09/14 05:57 AM, Simon Sapin wrote:
On 21/09/14 07:34, Daniel Micay wrote:
On 21/09/14 16:27 -0400, Evan G wrote:
Personally, I feel safety generalizes pretty well to any concept
that should be called out explicitly as unsafe--not just memory
safety.
You can feel that all you want, but memory safety is reasonably
straightforward to define in a general context,
On 21/09/14 04:27 PM, Evan G wrote:
Personally, I feel safety generalizes pretty well to any concept
that should be called out explicitly as unsafe--not just memory
safety.
That's not how Rust defines `unsafe`. It's open to misuse, and the
compiler will happily point out that it's not being
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
23 matches
Mail list logo
