-
Notifications
You must be signed in to change notification settings - Fork 88
Severe memory issues in basement strings #447
Comments
it's not necessarily clear cut for every of those usage, but it's seriously dodgy for toList which can be lazy at any point; I really can't think of any other way than doing a This need some rethink, the address based subtype is seriously underused and underspecified. I think maybe a foreign ptr equivalent of |
The fundamentally |
we could argue this, it's one of the few oversight of the difference between native and foreign object that cause many pain for the users. it's very likely that this problem would be solved much better with something like I'm not sure right now what's the best workaround here. demoting |
By tracking down some bugs, I found quite a few places where foundation strings aren't memory safe. The example I started from was
sToListStream
, particularly:The
onAddr
here basically ensures thefptr
holding the memory is available for zero time, as long as it takespure x
to evaluate thepure
part but not any of thex
part. Moreover, because of laziness, there's no way a singlewithFinalPtr
could ever work - you absolutely have to have awithFinalPtr
on eachPrimAddr.next
. Moreover, thatwithFinalPtr
and the correspondingtouch
inside it had really better occur in a fixed order with respect to accessing the underlyingAddr#
- so I thinkprimIndex
is fundamentally dodgy called on anything other than infinitely accessible constants. It's used heavily onString
, and I think that's a source of plenty of bugs.I suggest making
primIndex
in IO and fixing what it shows up, but at the very least you definitely need to fixsToListStream
andsToList
- and I'm certain I'll find more if you don't fix it in a way the type system prevents it.The text was updated successfully, but these errors were encountered: