6 ms·

So given that this isn't actually safe, you can presumably write some code that has undefined behaviour using this library for us?

ridiculous_fish 9y ago
Well that's the question, isn't it? Here's one scenario that might invoke UB: create a top level widget, call destroy() [1] on it, then use the widget. Does that invoke UB? If not, why not - how does Rust's ownership model interact with the GTK one? [1] http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.destroy http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.des...
- yorwba 9y ago
  I tried to test this by modifying the example on http://gtk-rs.org http://gtk-rs.org so that the window would be destroyed immediately after creation. When I ran it under valgrind, there were lots of memory access violations. (Valgrind: "Go fix your program!") I thought that would settle the matter, but then I ran the unmodified code, and it generated essentially the same error messages. Filing a bug report right now.
  - jcranmer 9y ago
    Looking at your bug report, the first few errors are in g_object code and have absolutely nothing to do with Rust, let alone gtk-rs. (It is known that jemalloc, Rust's allocator, doesn't play nicely with valgrind, but not even that is in play). Given that the stacks start with dbus, none of these errors are relevant to gtk-rs.
    - yorwba 9y ago
      I did not get any similar errors on other GTK apps I tested, so I'm relatively confident that it is at least somewhat related to the way gtk-rs does things. I do not seriously expect any Rust code to directly violate memory safety, but calling C code in GTK incorrectly can still have the same effect.
      - yorwba 9y ago
        For those still watching this thread: the memory accesses were correct, valgrind just couldn't handle the jemalloc allocator. Using the system allocator instead, even destroying the window before using it does not lead to invalid accesses.
        alphaalpha101 9y ago
        Isn't it still undefined behaviour to do so, though?
        yorwba 9y ago
        Valgrind doesn't detect anything, so I guess GTK's reference counting does the right thing and doesn't prematurely free data still referenced somewhere else. It just doesn't show a window.
sidlls 9y ago
Yes, it's possible to write unsafe code that exhibits undefined behavior in Rust in general (not just through FFI and bindings such as this).
- alphaalpha101 9y ago
  Sure, but this isn't unsafe code. Code using this library isn't written in an unsafe block, right? You just use it like any other Rust library?
  - leshow 9y ago
    If you're asking about gtk-rs, yes you use it just like a library. The only reason the unsafe block is there is because it does FFI. The Rust compiler inherently doesn't trust ffi calls. That doesn't mean necessarily that the call is actually unsafe.
    - alphaalpha101 9y ago
      If you write code that can be called without 'unsafe' then you are required to make that code safe. Whether you implement it using unsafe underneath is irrelevant. The unsafe block is there because it does FFI, which hasn't actually been verified to be safe.
      - leshow 9y ago
        You're rephrasing exactly what I said: > The Rust compiler inherently doesn't trust ffi calls. That doesn't mean necessarily that the call is actually unsafe.
  - sidlls 9y ago
    It's unsafe to Rust. Rust has defined safety to mean a certain thing. In order to support FFI in general the Rust compiler must assume nothing about the safety guarantees of the other language, and therefore that it should be considered "unsafe" according to Rust.
steveklabnik 9y ago
unsafe{} means "hey compiler, you cannot verify but this is safe, but I have." This code should be safe to use, unless the human involved has messed something up, in which case, it's a bug. It's more that the possibility for UB now exists, than it definitely does.
- alphaalpha101 9y ago
  I know what unsafe means. The issue is that this library's author presumably hasn't actually verified that it actually is safe.
- jononor 9y ago
  Maybe unsafe should be called assume_safe or presumably_safe or maybe_unsafe... People easily understand it wrong
  - steveklabnik 9y ago
    We considered many things, but in the end, nothing is perfect.

ridiculous_fish 9y ago

Well that's the question, isn't it? Here's one scenario that might invoke UB: create a top level widget, call destroy() [1] on it, then use the widget. Does that invoke UB? If not, why not - how does Rust's ownership model interact with the GTK one? [1] http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.destroy http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.des...

yorwba 9y ago
I tried to test this by modifying the example on http://gtk-rs.org http://gtk-rs.org so that the window would be destroyed immediately after creation. When I ran it under valgrind, there were lots of memory access violations. (Valgrind: "Go fix your program!") I thought that would settle the matter, but then I ran the unmodified code, and it generated essentially the same error messages. Filing a bug report right now.
- jcranmer 9y ago
  Looking at your bug report, the first few errors are in g_object code and have absolutely nothing to do with Rust, let alone gtk-rs. (It is known that jemalloc, Rust's allocator, doesn't play nicely with valgrind, but not even that is in play). Given that the stacks start with dbus, none of these errors are relevant to gtk-rs.
  - yorwba 9y ago
    I did not get any similar errors on other GTK apps I tested, so I'm relatively confident that it is at least somewhat related to the way gtk-rs does things. I do not seriously expect any Rust code to directly violate memory safety, but calling C code in GTK incorrectly can still have the same effect.
    - yorwba 9y ago
      For those still watching this thread: the memory accesses were correct, valgrind just couldn't handle the jemalloc allocator. Using the system allocator instead, even destroying the window before using it does not lead to invalid accesses.
      - alphaalpha101 9y ago
        Isn't it still undefined behaviour to do so, though?
        yorwba 9y ago
        Valgrind doesn't detect anything, so I guess GTK's reference counting does the right thing and doesn't prematurely free data still referenced somewhere else. It just doesn't show a window.

sidlls 9y ago

Yes, it's possible to write unsafe code that exhibits undefined behavior in Rust in general (not just through FFI and bindings such as this).

alphaalpha101 9y ago
Sure, but this isn't unsafe code. Code using this library isn't written in an unsafe block, right? You just use it like any other Rust library?
- leshow 9y ago
  If you're asking about gtk-rs, yes you use it just like a library. The only reason the unsafe block is there is because it does FFI. The Rust compiler inherently doesn't trust ffi calls. That doesn't mean necessarily that the call is actually unsafe.
  - alphaalpha101 9y ago
    If you write code that can be called without 'unsafe' then you are required to make that code safe. Whether you implement it using unsafe underneath is irrelevant. The unsafe block is there because it does FFI, which hasn't actually been verified to be safe.
    - leshow 9y ago
      You're rephrasing exactly what I said: > The Rust compiler inherently doesn't trust ffi calls. That doesn't mean necessarily that the call is actually unsafe.
- sidlls 9y ago
  It's unsafe to Rust. Rust has defined safety to mean a certain thing. In order to support FFI in general the Rust compiler must assume nothing about the safety guarantees of the other language, and therefore that it should be considered "unsafe" according to Rust.

steveklabnik 9y ago

unsafe{} means "hey compiler, you cannot verify but this is safe, but I have." This code should be safe to use, unless the human involved has messed something up, in which case, it's a bug. It's more that the possibility for UB now exists, than it definitely does.

alphaalpha101 9y ago
I know what unsafe means. The issue is that this library's author presumably hasn't actually verified that it actually is safe.
jononor 9y ago
Maybe unsafe should be called assume_safe or presumably_safe or maybe_unsafe... People easily understand it wrong
- steveklabnik 9y ago
  We considered many things, but in the end, nothing is perfect.