Hi everyone,
I've been tossing around an idea for a library utility designed to make
unique pointers easier to use, especially for balanced binary search
trees and the like. The core of the idea is that I conjecture it's safe
to temporarily violate linearity *while the locations in question ar
I just tested this in my code, it solved a sticky problem I had with
updating owned data nested deep inside a tree-ish container. My original
solution wasn't very nice (it just compromised on efficiency and copied too
much data around). The new code is shorter and more efficient (no copies!
yey!).
On 8/30/13 3:39 PM, Patrick Walton wrote:
Thoughts? Does this seem useful? Are there soundness issues I didn't
notice?
Brian pointed out a massive soundness hole in this, unfortunately. The
problem is that you can read from the original locations; the right to
read is not "shut off" during th
Sigh, I guess it was too good to be true :-(
I'd settle for the ability to say: update_in_place(foo.owned_pointer,
&fn(~T) -> ~T) - surely this would be safe?
Speaking of which, a secondary problem I encountered when doing this sort
of thing, is the "Once function" issue listed in
https://github.
> I'd settle for the ability to say: update_in_place(foo.owned_pointer, &fn(~T)
> -> ~T) - surely this would be safe?
That would interact with Drop in a way that could cause a memory violation
after a task failure. The problem is that if you allow a moved value to be
destroyed before something
Since swap seems to have its own problems - would it be possible to tweak
the stealing idea so the compiler would know there's a burrowed mutable
pointer to the hole, effectively preventing further access to it in the
vulnerable block?
I really would like to be able to use this approach, it really
On 9/1/13 8:23 AM, Oren Ben-Kiki wrote:
Since swap seems to have its own problems - would it be possible to
tweak the stealing idea so the compiler would know there's a burrowed
mutable pointer to the hole, effectively preventing further access to it
in the vulnerable block?
I really would like
On Fri, Aug 30, 2013 at 05:50:40PM -0700, Patrick Walton wrote:
> Brian pointed out a massive soundness hole in this, unfortunately.
> The problem is that you can read from the original locations; the
> right to read is not "shut off" during the borrow. I think the fix
> would have to be to replace
Sorry, sent that e-mail prematurely. Short version is that I think we
could generalize our move rules somewhat precisely for the purpose of
accommodating this situation, but the question is whether it would
ultimately be expressive enough. There would have to be rules against
making fn calls, readi
Another thought on this. Currently, either the compiler is satisfies that
the code is 100% safe, or we slap an "unsafe" keyword around the code and
put 100% of the responsibility on the programmer, with no support from the
Rust system.
Wouldn't it make sense to have a "not statically safe, but ver
On 9/7/13 8:39 AM, Oren Ben-Kiki wrote:
I have a feeling that there is a non-trivial amount of code which is
"actually safe" but would impossible to convince the compiler it is
"statically safe". Surely having run-time safety in such cases is better
than none at all...?
I would be fine with thi
Is there any system in actual use where actually dereferencing a null
pointer will not cause an exception? I mean, _sure_, the C spec says the
result is "undefined", but isn't this just a leftover from the "bad old
days", like also supporting non-byte-addressible machines (with
non-power-of-two wor
On Sat, Sep 7, 2013 at 12:09 PM, Oren Ben-Kiki wrote:
> If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...)
> every null pointer will fault (which I strongly hope will...), then I'd be
> quite happy in saying formally that accessing a hole leads to "undefined
> behavior" and
I miss-spoke; when I said "machine" I meant "platform" (combination of HW
and SW). Is unintentionally dereferencing a null pointer a silent error on
any existing platform?
But isn't a very good question either. A better one would be: Would it be
_useful_ to define `steal` and use it in programs, s
On Sat, Sep 7, 2013 at 4:15 PM, Oren Ben-Kiki wrote:
> I miss-spoke; when I said "machine" I meant "platform" (combination of HW
> and SW). Is unintentionally dereferencing a null pointer a silent error on
> any existing platform?
>
Yes, it's only a segmentation fault in userland code on platfor
To clarify why undefined behavior is really bad in practice: if LLVM ever
detects that your code performs undefined behavior according to the standard,
it is *designed* to take full advantage of that fact when making optimizations.
In other words, all hell will break lose, in potentially very c
On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote:
> To clarify why undefined behavior is really bad in practice: if LLVM ever
> detects that your code performs undefined behavior according to the
> standard, it is *designed* to take full advantage of that fact when making
> optimizations. I
Alas. So I guess it all depends on someone finding a smart safe way to
generalize the swap operation, or something... as things stand, it is
extremely difficult to efficiently and safely implement complex nested
containers. I will admit I am using the `steal` function for now, it just
makes things
On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote:
> On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote:
> To clarify why undefined behavior is really bad in practice: if LLVM ever
> detects that your code performs undefined behavior according to the standard,
> it is *designed* to take full
On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote:
>
> On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote:
>
> > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote:
> > To clarify why undefined behavior is really bad in practice: if LLVM
> ever detects that your code performs undefined behav
On Sat, Sep 7, 2013 at 4:42 PM, Daniel Micay wrote:
> On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote:
>
>>
>> On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote:
>>
>> > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote:
>> > To clarify why undefined behavior is really bad in practice:
On Sep 7, 2013, at 1:42 PM, Daniel Micay wrote:
> On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote:
>
> On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote:
>
> > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving wrote:
> > To clarify why undefined behavior is really bad in practice: if LLVM e
On Sat, Sep 7, 2013 at 4:47 PM, Geoffrey Irving wrote:
> On Sep 7, 2013, at 1:42 PM, Daniel Micay wrote:
>
> > On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving wrote:
> >
> > On Sep 7, 2013, at 1:32 PM, Daniel Micay wrote:
> >
> > > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving
> wrote:
> >
23 matches
Mail list logo
