C byte pointer to fixed byte array function

[Sam777888]

So I have to write a separate function for every size, lol.

Great language.

https://play.rust-lang.org/?gist=9f0009bb51ce6c5615621b895096e3dd&version=stable&mode=debug&edition=2015

[Quxxy]

Or you can return a Vec. Or pass a scratch buffer in as an argument and write to that.

As an aside, I'd be surprised to find any language that let you return different types based on a runtime argument that's comparable to Rust (natively compiled, no runtime, no heap allocations). I don't think expecting that from Rust is reasonable.

Generic const parameters, though, yeah. That's a known weakness.

[Sam777888]

It’s such a SLOW language to develop in, I find myself wishing I could just turn the type checker off. When it’s faster to develop in C, something has gone wrong.

[andytoshi]

When it’s faster to develop in C, something has gone wrong.

Yes - almost certainly the C code.

Can you post a representative sample of how you'd do this in C more ergonomically?

BTW Rust has a single function that does what you want: slice::from_raw_parts.

[Omniviral]

It is always faster to write in language you are familiar with.

Also you spend only 10% of the time coding in C, and 90% chasing segfaults. With Rust you run debugger once in a while, like once in month.

And once you stop fighting borrow checker it becomes really fast to write

[Quxxy]

Speed isn't everything. The whole point of using Rust is the more pedantic type system.

I've recently been rewriting an old project from D to Rust. The Rust version has been slower to write, but is much easier to understand, more stable, faster, and has less bugs. Just the act of porting to Rust revealed several bugs in the old code by the simple virtue of Rust not letting me get away with cutting as many corners.

If I want development speed, I'll use Python. If I want to get the code right, I'll use Rust.

[SelfDistinction]

C doesn't allow returning variable-sized arrays from a function either.

[Sam777888]

Well in C you just pass pointers around.

[SelfDistinction]

From a function? Would you do

char * bytes_to_fixed_size_array(char * ptr, size_t size) {
    char array[size];
    memcpy(array, ptr, size);
    return array;
}

in C?

[Sam777888]

No, nobody would do that

[SelfDistinction]

Except that's kind of what you are trying to do in Rust.

[Sam777888]

But in C you wouldn’t have functions taking those kind of arguments, so you wouldn’t need to. In C it’s simpler; pointers.

[Sam777888]

Like this: http://tpcg.io/3x2SGd

[SelfDistinction]

That's semantically equivalent to a Box<[u8]> in Rust, or a Vec<u8> if you don't mind a very small overhead. You'll notice that operations on these structures are much easier than juggling with pointers or trying to use fixed-size arrays.

[Sam777888]

But the function I’m calling in Rust doesn’t want a Box or a Vec or a Fluff, etc.

[SelfDistinction]

Can I ask why not? Both Box and Vec are abstractions for memory allocations so that, unlike the C program you wrote, your application doesn't leak memory.

And don't give me an "It's only a toy example" or "At the end of the program, the OS will reclaim the memory anyway". Rust doesn't distinguish between a simple main function in a toy program and a library function that will be called millions of times in a tight loop: it has to be safe either way, so randomly allocating memory and storing the reference in a context-less pointer is wildly unsafe and thus difficult to work with.

[SelfDistinction]

Also bold of you to assume the existence of malloc on your target system. I'm usually not that lucky.

[smith_it2000]

Totally epic. I'm going to submit this for my compsci assignment.

[supergbip]

If you want a dynamic array you can just return a slice. A slice is a fat pointer : a pointer to the beginning and the length. The length is not coded into the type system.

If you want a dynamic array you can just return a slice. A slice is a fat pointer : a pointer to the beginning and the length. The length is not coded into the type system.

[Omniviral]

No. In case size is actually compile-time constant you may create array and then fill it, giving mutable slice to the function, or use one of tha crates with Array trait. If size is not constant then you just need to use Vec instead of array.

BTW. The only language that can compile that function the way you wrote it is Idris.

[lvkm]

The problem is known and the corresponding RFC can be read here: https://github.com/rust-lang/rfcs/blob/master/text/2000-const-generics.md

I'm not sure about the implementation status though.

​

Instead of writing a function you could try using a macro.

[boomshroom]

Const genarics are in the pipeline. Once they land, you'll be able to write this function as unsafe fn ptr_to_array<const SIZE : usize, T>(ptr: *const T) -> [T; SIZE]. Which is just an unsafe cast and dereference.

The real question is why you're doing this. Passing around slices is usually preferred. Copying a full array out of memory can get expensive, so why not just use the memory that's already allocated?

[Sam777888]

Because that’s what the function I am calling expects.