I found it. Wow that is a take. I am surprised CStr::as_ptr is still around letting folks get bit by this. Wasn't there talk of deprecating it in favor of a method that returns a reference at some point?
-
-
I'd argue CStr / CString should be deprecated entirely and replaced with safe types that are FFI compatible. There shouldn't be a need for any raw pointers at all.
1 reply 0 retweets 3 likes -
No. I don't think that works. As someone who has written a LOT of ffi, you need these kinds of types and I'm not sure how to make these more FFI safe in the first place
1 reply 0 retweets 3 likes -
This Tweet is unavailable.
-
but it's not an &c_char? But yes, having safer bindings using pointers works. you still need the raw stuff a lot
2 replies 0 retweets 2 likes -
This Tweet is unavailable.
-
This Tweet is unavailable.
-
Even if the function is declared as taking a pointer, references implicitly coerce, so it's rather moot what the decl uses IMO
1 reply 0 retweets 0 likes -
Er, to clarify my tweet, my problem is not with using &, it's that the type being taken is fundamentally a pointer to a list of chars, not just one, and it would be nicer if a separate type existed for that, the way we have c_void
1 reply 0 retweets 2 likes -
Replying to @ManishEarth @sgrif and
would
@oli_obk's procedural vtable RFC address this?2 replies 0 retweets 0 likes
I don't think it would help when you're dealing with code that wants a raw thin pointer
-
-
Replying to @sgrif @ManishEarth and
I don't understand why not, this seems to be a custom vtable as a thin pointer https://github.com/oli-obk/rfcs/blob/procedural-vtables/text/0000-procedural-vtables.md#null-terminated-strings-stdfficstr …
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.