I think its quite important especially when you get 100K to 1M line
projects knowing what is safe .. Nothing more annoying that c Heisenbugs
some which took a decade to track down . If the c lib is mature people
will write wrappers and with a bit of luck eventually the wrappers may
mature into sa
On 10/15/2012 08:14 AM, Niko Matsakis wrote:
(Note: we somehow lost the rust-dev cc, see Stefan's e-mail below)
Under the plan as I envisioned it in my head, ignoring the question
about unsafety, it would be necessary to write a wrapper for a C
function if you wanted it to have the same type as
On 12-10-15 08:27 AM, Marijn Haverbeke wrote:
The question I guess is how often this situation comes up. Is it
just libmath? Or is this sort of thing extremely common when doing
bindings?
Extremely common. I'm somewhat appalled that the blanket 'all C
functions are unsafe' idea is
Am 15.10.2012 um 17:27 schrieb Marijn Haverbeke :
> The question I guess is how often this situation comes up. Is it just
> libmath? Or is this sort of thing extremely common when doing bindings?
>
> Extremely common. I'm somewhat appalled that the blanket 'all C functions are
> unsafe' idea
I am +1 for this.
In my experience writing many foreign library bindings in Haskell
(I've done it a lot,) the vast majority of people who will ever do
this are going to do it in a library and offer it up there. As an
author, I find it often pays off the most in the long (for users) to
wrap things
On 10/15/12 8:27 AM, Marijn Haverbeke wrote:
Extremely common. I'm somewhat appalled that the blanket 'all C
functions are unsafe' idea is even being considered (and
enthusiastically supported). Yes, C code can segfault and do other nasty
things if you call it incorrectly. But wrapping every call
>
> The question I guess is how often this situation comes up. Is it just
> libmath? Or is this sort of thing extremely common when doing bindings?
>
Extremely common. I'm somewhat appalled that the blanket 'all C functions
are unsafe' idea is even being considered (and enthusiastically supported
(Note: we somehow lost the
rust-dev cc, see Stefan's e-mail below)
Under the plan as I envisioned it in my head, ignoring the question
about unsafety, it would be necessary to write a wrapper for a C
function if you wanted it to have the same type as a Rust fn (as opposed
to an `extern "C" fn(
Am 12.10.2012 um 21:29 schrieb Niko Matsakis :
> +1 (one developer, one vote!) ;)
>
will there be a way to explicitly mark them as safe? Asking because if we go
down this route, all calls in libmath will become unsafe without wrapping them
in functions with unsafe blocks and that seems wrong
On 12-10-12 11:38 AM, Brian Anderson wrote:
On 10/12/2012 10:41 AM, Patrick Walton wrote:
This is bug #2628: https://github.com/mozilla/rust/issues/2628
After hacking on Servo I feel very strongly about this now. The vast
majority of exploitable crashes are in code that Rust considers safe. In
+1 (one developer, one
vote!) ;)
Brian Anderson
October 12, 2012
11:38 AM
+2
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Patrick Walton
October 12, 2012
10:41
On 10/12/2012 10:41 AM, Patrick Walton wrote:
This is bug #2628: https://github.com/mozilla/rust/issues/2628
After hacking on Servo I feel very strongly about this now. The vast
majority of exploitable crashes are in code that Rust considers safe. In
fact, I feel that if we *don't* do this, then
This is bug #2628: https://github.com/mozilla/rust/issues/2628
After hacking on Servo I feel very strongly about this now. The vast
majority of exploitable crashes are in code that Rust considers safe. In
fact, I feel that if we *don't* do this, then we aren't any safer than
C++ in a practical
13 matches
Mail list logo
