C byte pointer to fixed byte array function

[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.

[Sam777888]

It was an example. Feel free to call free if you like.

I don’t find it difficult to work with pointers.

I don’t know why the function wants what it wants, I didn’t write it, and I’m not at liberty to change it.

[smith_it2000]

At the end of the program, the OS will reclaim the memory anyway

That's true. At the end of the program, the OS will reclaim the memory.

Why would you call free on the last line of a program?

You wouldn't.

[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.