Stream: general

Topic: core::ffi::CStr ?


gnzlbg (Nov 06 2018 at 16:49, on Zulip):

why is std::ffi::CStr not in core ?

gnzlbg (Nov 06 2018 at 16:50, on Zulip):

or in libc ?

gnzlbg (Nov 06 2018 at 16:50, on Zulip):

it might not make sense for core because it would require libc for c_char, but it could be exposed in libc so that one does not need libstd to use it

Nicole Mazzuca (Nov 06 2018 at 16:56, on Zulip):

@gnzlbg because right now, CStr is not really ffi safe

Nicole Mazzuca (Nov 06 2018 at 16:56, on Zulip):

if it were a thin pointer, maybe

Nicole Mazzuca (Nov 06 2018 at 16:56, on Zulip):

although maybe there's an argument for core

gnzlbg (Nov 06 2018 at 16:57, on Zulip):

we could put it in core if we require char to be 1 byte in the UCG

gnzlbg (Nov 06 2018 at 16:57, on Zulip):

but otherwise, core does not know c_char

gnzlbg (Nov 06 2018 at 16:58, on Zulip):

@Nicole Mazzuca why isn't CStr just a *[const,mut] c_char ?

gnzlbg (Nov 06 2018 at 16:59, on Zulip):

is there a way to make a type be "unsized" ?

gnzlbg (Nov 06 2018 at 16:59, on Zulip):

e.g. struct CStr(*mut c_char); impl !Sized for CStr {}

Nicole Mazzuca (Nov 06 2018 at 17:00, on Zulip):

nope

Nicole Mazzuca (Nov 06 2018 at 17:00, on Zulip):

not as of yet

Nicole Mazzuca (Nov 06 2018 at 17:00, on Zulip):

it's a struct CStr([c_char]); right now

Nicole Mazzuca (Nov 06 2018 at 17:00, on Zulip):

which means it's unsized, but not thin

gnzlbg (Nov 06 2018 at 17:01, on Zulip):

is there an unsized type that's one pointer wide ?

Nicole Mazzuca (Nov 06 2018 at 17:02, on Zulip):

no

Nicole Mazzuca (Nov 06 2018 at 17:02, on Zulip):

not right now

Nicole Mazzuca (Nov 06 2018 at 17:02, on Zulip):

we need custom DSTs

gnzlbg (Nov 06 2018 at 17:04, on Zulip):

lol, even trait objects of traits without methods are 16 bytes wide

gnzlbg (Nov 06 2018 at 17:05, on Zulip):

why ?

Nicole Mazzuca (Nov 06 2018 at 17:05, on Zulip):

because nobody has put in the work to do this yet

Nicole Mazzuca (Nov 06 2018 at 17:06, on Zulip):

and for that, because you still need size, align, and drop

gnzlbg (Nov 06 2018 at 17:06, on Zulip):

trait Bar {} struct CStr(dyn Bar); could work iff dyn Bar would be pointer sized because there is no need for a vtable pointer

RalfJ (Nov 06 2018 at 17:07, on Zulip):

@gnzlbg also even if the trait has no method you need a vtable for size, alignment and drop

gnzlbg (Nov 06 2018 at 17:07, on Zulip):

oh

RalfJ (Nov 06 2018 at 17:07, on Zulip):

there is @eddyb's trick with extern type

Nicole Mazzuca (Nov 06 2018 at 17:07, on Zulip):

but then you lose size_of_val

RalfJ (Nov 06 2018 at 17:07, on Zulip):

because it turns out that with extern { type Foo; }, Foo is DST and thin

Nicole Mazzuca (Nov 06 2018 at 17:08, on Zulip):

which is a breaking change

RalfJ (Nov 06 2018 at 17:08, on Zulip):

but yeah there are lots of unanswered questions around that

RalfJ (Nov 06 2018 at 17:08, on Zulip):

@Nicole Mazzuca I suppose CStr wants to be a custom DST where size_of_val does strlen?

Nicole Mazzuca (Nov 06 2018 at 17:08, on Zulip):

yes

gnzlbg (Nov 06 2018 at 17:08, on Zulip):

yes

gnzlbg (Nov 06 2018 at 17:09, on Zulip):

I mean, its in std::ffi::CStr, and its not FFI safe

Nicole Mazzuca (Nov 06 2018 at 17:09, on Zulip):

yeah

Nicole Mazzuca (Nov 06 2018 at 17:09, on Zulip):

it's quite ridiculous

gnzlbg (Nov 06 2018 at 17:10, on Zulip):

we don't need full DST for this, some rustc_ magic to allow implementing it would suffice

Nicole Mazzuca (Nov 06 2018 at 17:10, on Zulip):

that seems... unfortunate

gnzlbg (Nov 06 2018 at 17:11, on Zulip):

i mean, full DSTs would be cool but i wouldn't block fixing CStr on it

Nicole Mazzuca (Nov 06 2018 at 17:11, on Zulip):

it also seems like a lot of work for that

Nicole Mazzuca (Nov 06 2018 at 17:12, on Zulip):

*just that

Nicole Mazzuca (Nov 06 2018 at 17:12, on Zulip):

frankly, we should just fix DSTs now

Nicole Mazzuca (Nov 06 2018 at 17:12, on Zulip):

as opposed to inventing a solution for exactly one type

gnzlbg (Nov 06 2018 at 17:12, on Zulip):

re-open the RFC ?

Nicole Mazzuca (Nov 06 2018 at 17:12, on Zulip):

yeah

Nicole Mazzuca (Nov 06 2018 at 17:12, on Zulip):

alright

Nicole Mazzuca (Nov 06 2018 at 17:12, on Zulip):

ping me in 10 hours?

Nicole Mazzuca (Nov 06 2018 at 17:13, on Zulip):

I'll put in the work to get it up to snuff

gnzlbg (Nov 06 2018 at 17:13, on Zulip):

i'll be sleeping in 10 hours probably

Nicole Mazzuca (Nov 06 2018 at 17:13, on Zulip):

fair

gnzlbg (Nov 06 2018 at 17:13, on Zulip):

will be 2 am over here :D

Nicole Mazzuca (Nov 06 2018 at 17:13, on Zulip):

well, no promises, but if I remember lol

Nicole Mazzuca (Nov 06 2018 at 17:13, on Zulip):

where are you?

gnzlbg (Nov 06 2018 at 17:13, on Zulip):

germany

Nicole Mazzuca (Nov 06 2018 at 17:13, on Zulip):

ah, cool

gnzlbg (Nov 06 2018 at 17:14, on Zulip):

:D

eddyb (Nov 06 2018 at 17:39, on Zulip):

Frankly we could add an unstable DynSized trait that overloads the size_of_val that you'd get for a DST

gnzlbg (Nov 06 2018 at 17:39, on Zulip):

that would solve the problem for CStr at least, and we can punt figuring out custom DST until later

eddyb (Nov 06 2018 at 17:40, on Zulip):

I'm not sure it would even be that hard, you just treat the compiler-provided one as a default fn method

eddyb (Nov 06 2018 at 17:40, on Zulip):

but I'd also clue in @nikomatsakis first

RalfJ (Nov 06 2018 at 17:47, on Zulip):

from a miri perspective I am actively scared of size_and_align_of_mplace executing arbitrary code

kennytm (Nov 06 2018 at 17:48, on Zulip):

what if we require the overridden size_of_val/align_of_val to be const

kennytm (Nov 06 2018 at 17:49, on Zulip):

(assuming strlen can be const)

RalfJ (Nov 06 2018 at 17:50, on Zulip):

uh that is an interesting idea

RalfJ (Nov 06 2018 at 17:50, on Zulip):

doesnt make me less scared TBH but still interesting^^

gnzlbg (Nov 06 2018 at 17:50, on Zulip):

strlen can be a const fn, but we will want to call C's strlen when it is not executed at compile-time

RalfJ (Nov 06 2018 at 17:50, on Zulip):

I think we should be calling our own TBH

gnzlbg (Nov 06 2018 at 17:51, on Zulip):

@RalfJ that might be a big performance regression at run-time

kennytm (Nov 06 2018 at 17:52, on Zulip):

i suppose the runtime strlen would involve SIMD and maybe read slightly beyond the allocated region

gnzlbg (Nov 06 2018 at 17:52, on Zulip):

the one in the C library might do run-time feature detection for large strings, use SSE, AVX, ... intrinsics, inline assembly, or even be fully written in assembly

gnzlbg (Nov 06 2018 at 17:52, on Zulip):

i forgot the trick of reading out of bounds

kennytm (Nov 06 2018 at 17:53, on Zulip):

we could always turn strlen into an intrinsic :upside_down:

gnzlbg (Nov 06 2018 at 17:54, on Zulip):

yeah, the goalt here isn't evolving custom DST or const fn, but fixing CStr

kennytm (Nov 06 2018 at 17:58, on Zulip):

do we need a thin CStr today? core::ffi::CStr only needs a core::ffi::c_char. if you need to pass the CStr into FFI functions you could still use .as_ptr()

Nicole Mazzuca (Nov 06 2018 at 18:05, on Zulip):

no, but it's confusing and frustrating to do that

gnzlbg (Nov 06 2018 at 18:10, on Zulip):

it would make working with C FFI so much better, working with *mut c_char sucks and is very error prone (forgot to check the \0 terminator ? etc. )

eddyb (Nov 06 2018 at 18:22, on Zulip):

C strings and element-pointer+length arrays are the only thing in Rust's FFI to LLVM that are not safe types right now

eddyb (Nov 06 2018 at 18:22, on Zulip):

since @irinagpopa made all of the LLVM classes be used by reference (relying on extern type ofc)

Nicole Mazzuca (Nov 06 2018 at 19:09, on Zulip):

@gnzlbg https://internals.rust-lang.org/t/pre-rfc-custom-dsts/8777

RalfJ (Nov 06 2018 at 20:54, on Zulip):

re miri: even with const fn this requires machine steps to execute for determining the size. that's just scary^^

RalfJ (Nov 06 2018 at 20:55, on Zulip):

@kennytm uh I dont think reading beyond the allocated region is something LLVM allows you to do^^

gnzlbg (Nov 07 2018 at 09:17, on Zulip):

@Nicole Mazzuca thanks!

Last update: Nov 22 2019 at 00:25UTC