I'll note that Ada developers have been writing high-performance or real-time code in C's domain for some time without relying too much on unsafe pointers. They mostly use references or restricted pointers. It has additional benefit of separating types from how many bits represent them where miles and kilometers might be 32 bit but compiler error if you mix them. Also, bounds-checks on arrays or pointers. Then, SPARK subset that verifies absence of common vulnerabilities has no pointers at all. People still manage to build useful things like the IRONSIDES DNS server.

http://www.adacore.com/knowledge/technical-papers/safe-and-s...

https://en.wikipedia.org/wiki/SPARK_(programming_language)

http://ironsides.martincarlisle.com/

These show the advantages of C's pointers are overstated in the general case. Actually a drawback if building high-integrity software. Worst case, we write just those few algorithms in C, unsafe Ada, unsafe Rust, assembly or whatever then wrap them in strongly-typed, safer functions with input validation when called. That's standard in safe languages. Probably how Rust people do it, too.

It's just a different set of tradeoffs.

Rust's raw pointers have equivalent power to C's pointers.

Not native, see C.

>Rust's raw pointers have equivalent power to C's pointers.

Again, AFAIK you can't do type punning.

That wasn't even my point, that was that C gives you almost everything a cpu does and not much more.

Bitflags crate is native; 100% Rust, 0% C. Here is the source: https://github.com/rust-lang-nursery/bitflags/blob/master/sr...

But i give up, as this isn't a technical discussion.

To be honest, I don't know if a functional difference, but I have not done any embedded programming where there might be a difference.

Now, I never did it that way myself. I just and-ed it with a bitmask to get the part that I wanted. But it's a bit messier to do it that way, because if you want one of the fields as a number, and it's not from the least-significant bits, then you have to shift it as well as mask it, whereas with bitfields you can just read it as a number and get the right value.

Never bothered me on Turbo Pascal days, plus if I remember correctly bitfield ordering is not portable across compilers anyway.

I suspect it's the same with type punning (though also, to some degree because we're still working out the details of what exactly the semantics of unsafe are.) In the end, you can always cast stuff to bytes and then cast those bytes to something else.

I don't take (too much) objection to that, and little with "not much more", but that doesn't mean that C has some secret stuff that only C can do, which it feels like you're implying.

I don't know how that macro works, but in kernel C bitfields are used in structs that map to device registers (that are mapped to memory).

>I suspect it's the same with type punning (though also, to some degree because we're still working out the details of what exactly the semantics of unsafe are.) In the end, you can always cast stuff to bytes and then cast those bytes to something else.

So if i want to store a series of things with random (length) types in a single array, i can ? Sounds like i can, even though you explained the simpler case.

>I don't take (too much) objection to that, and little with "not much more", but that doesn't mean that C has some secret stuff that only C can do, which it feels like you're implying.

And for the third (edit:second) time, that is not my point. Thing is that C does not have "secret stuff" and rust does. In C you get what you wrote, and not much more. There is no need for telling the compiler to not do some checking or to not make a copy of something. (edit2: granted, bitfields are not native to cpus as type punning is)

Rust, IMO, is more for the C++ crowd then C. And those two are very different.

This is really not the case, not with modern C compilers. You may find calls to functions from the standard library to be converted in surprising ways, while touching undefined behaviour can eliminate evaluations, branches, function calls and more. Your mental model might have a close resemblance to assembly; but compilers don't see it like that any more.

Yes, things like memcpy and printf are (in most cases) built-in in compilers. Not surprising really.

Undefined behavioral is bad programming, if your ask me. Almost all examples of it, that i ran across, are in really ugly code that only a "smart" programmer would write.

Clangs static analyzer points out undefined behavior, and gcc is close to getting a "-Wundefined" flag that points that out at compile time.

A optimizing C compiler can change the resulting code even more then just doing dead code elimination. But the point still stands, that C maps well to assembly and that languages that do things like their own memory allocation are not even comparable to what the cpu provides (only automatic memory allocation that a cpu somewhat provides is the stack, and C exposes even that).

Commonly-used type punning techniques frequently exhibit undefined behavior due to strict aliasing: https://blog.regehr.org/archives/1307 .

It might be true but barely matters when we have tools like KCC. It's built on an executable semantics of C that runs in a framework on top of Maude rewrite engine.

http://www.kframework.org/index.php/Main_Page

https://github.com/kframework/c-semantics

http://fsl.cs.illinois.edu/FSL/papers/2015/hathhorn-ellison-...

Same thing. There's no requirement to use it in a kernel context, though you can if you'd like.

> So if i want to store a series of things with random (length) types in a single array, i can ? Sounds like i can, even though you explained the simpler case.

Yes, though it'd use a lot of unsafe code.

> And for the third (edit:second) time, that is not my point. Thing is that C does not have "secret stuff" and rust does.

Ah, sorry! The contrapositive (or whatever) is tough. My bad for misunderstanding.

And no-no should program in assembly unless they know exactly what they're doing.