Clarification needed on the size of externals

[DavidGHorsman]

I am reviewing externals and found this comment and code.

@dgrunwald commented on Mar 2

&CStr was originally supposed to be compatible with *mut c_char for FFI purposes. (with CStr being an unsized type)

It's only a fat pointer because of Rust's current limitations .

struct CStr([libc::c_char]);
impl Dst for CStr {
    type Meta = ();
}

impl Sizeable for CStr {
    fn size_of_val(&self) -> usize {
        libc::strlen(self.as_ptr())
    }
}

impl CStr {
    pub unsafe fn from_ptr(p: *const libc::c_char) -> &CStr {
        // either
        std::mem::transmute::<*const libc::c_char, &CStr>(p)
        // or
        std::ptr::make_fat_ptr(p as *const (), ())
    }
}

It says closed on 1524 here:

Custom Dynamically Sized Types for Rust

It appears to be the default behavior for (internally) sizeable (external, lol) c types.

Up until now I have been assuming for types, where only the external code can determine size, that this is a Sizeof Trait.

This Traits fn's in turn make unsafe external calls to retrieve size. In theory...

This assumption seems to precisely emulate and be a subset / overload of the code above. So this has been addressed already me thinks.

1. Yes? No?

2. Is this standardized?

3. Recommended further reading?

[gnzlbg]

I'm not sure what you mean by "external" and "internal". Could you show an example that explain what you mean by these words? Thanks.

[DavidGHorsman]

'Sure. My apologies, the vagueness reflects my knowledge level. It's a managerial question to low level programmers about dynamic (external language) programming.

Repharased, I was thinking of types created in external libraries or other environments where the size is unknown to Rust.

Is the best practice to create a trait?

For example the trait in turn could make an unsafe (external to Rust) call to the other environment to query the size of the type. I could pull it (size) out of the data too potentially.

Can I assume all this controversy over the size of ALL types, external in particular, is resolved? I could not find where it was. I can't imagine how it could be.

CONTEXT: I need to handle objects both local and passed over networks and from exotic environments (PICK for example.)

My top candidates for crates (ie provisionally. I will add the links today) is:

brson/stdx

The static types library: [editme] Suggestions?

The persistence library:

serde-rs/serde

https://serde.rs/

And the crates graph page. https://crates.io/keywords/graph

A BTree indexing and object database combo (like Mongo)

These are requirements for (yet) another debate application. Web UI.

Someone fixed my OP? Thanks again. I am not entirely sure if this was using group correct terms. Is this post too long?

[DavidGHorsman]

More context. I have these folders open.

(EDIT I am looking for a technical answers overall. Also, I can format externally.)

[DavidGHorsman]

Crates of interest: (ed. Not covered in the book.)

[DavidGHorsman]

Temporary OPINION.

From my point of view:

 A C string is as long as the
 number of characters
 between the beginning
 of the string and the
 terminating null character
 (without including the
 terminating null 
character itself).

Represents ".len()" and is a LINT due to it's idiotic performance cost.

I love fat pointers as they are more frame / object friendly.

I view them as analogs to object in C# given they can be extended.

Another analog is macros. I prototyped a (working) mutlivalued objects / fields as operator overloads. (Extended the language.)

My point being that (macros) is how you extend syntax here and operators are available.

And while both are highly optimized Rust is uniquely designed (zero cost no GC) It mercifully lacks DotNet but... give it time. Probably a crate already.

END.

[DavidGHorsman]

Footnote: C# strings another non-issue. I this author:

Calling C# natively from Rust.

Knowledgeable enough to say this:

Instead, expose the CLR free method like so...

Paid a big performance hit by not making a C friendly fat pointer on the c# side. It was supposed to be general advice and he works with frames of data. Equally true of buffers say.

So I lack issues so far where external objects are concerned. That could be ignorance talking though.

[CAD97]

This feels like more of a urlo problem.

Cross-language cooperation is always going to be hard. Rust (will) offers extern type to create opaque types that Rust knows nothing about (unknown size, unknown alignment), and you're in charge of getting and using any information required to use them from FFI.

Custom dynamically sized types are planned eventually, but are very thorny to specify, so are a ways off yet as closer improvements are of higher importance currently (2019 was chosen to be a year for maturity, after all).

It feels like you're just starting with Rust. I'd definitely focus on working solely within Rust first, and getting help on urlo, discord, or the subreddit when you get stuck. Very few things are actually unsized in Rust currently: it's basically fat pointers for slices (&[T] is roughly (ptr, len)) and trait objects (&dyn T is roughly (ptr, &vtable)). Everything else is currently monomorphized such that size/alignment/etc is statically known.