Initial Rust DRM Abstractions, AGX Apple DRM Driver Posted For Review

[Weasel]

I should not need to explain this one. Why should you not mix C++ run-times we have done this one before because of memory management right weasel. As you said the last time if you are careful you can mix incompatible C++ runtime and not cause too much hell.

You can use C memory allocation API from C++... or any other resource management API...

Mixing isn't a language issue in the slightest, it's just API/interface issue. Same way you can use C++ memory allocation APIs from C, although it's more painful (but it can be done, you need to know the mangled symbol names though, Wine does it in the C++ runtimes which C++ apps normally interact with, but they're implemented in C on Wine!).

[oiaohm]

You can use C memory allocation API from C++... or any other resource management API...

https://rules.sonarsource.com/c/RSPEC-984

There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls.
You are attempting push a lie to get your way out Weasel. C memory allocation can mess with dynamic heap in ways C++ runtime/implementation is not expecting and bring the house down. Some C memory allocations API can be used from C++ not all. C++ and C does in fact have different memory models and different resource management models weasel. Yes the memory models and resource models is close enough that people fail to notice the differences most of the time. Yes gcc C with gcc C++ of the same gcc versions it possible to bring house down.

C replicating C++ runtime is fairly safe. C being used with C++ runtime that is not C++ compatible in memory/resource usage is fatal. Weasel its about time you stop pushing myth that you can just use any C memory allocation API form C++ because you cannot do this. Same reason why Microsoft says do not mix C++ runtime versions where possible is the some of this is the same reason why mixing C with C++ can be deadly Weasel.

[Weasel]

https://rules.sonarsource.com/c/RSPEC-984
There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls.
You are attempting push a lie to get your way out Weasel. C memory allocation can mess with dynamic heap in ways C++ runtime/implementation is not expecting and bring the house down. Some C memory allocations API can be used from C++ not all. C++ and C does in fact have different memory models and different resource management models weasel. Yes the memory models and resource models is close enough that people fail to notice the differences most of the time. Yes gcc C with gcc C++ of the same gcc versions it possible to bring house down.

C replicating C++ runtime is fairly safe. C being used with C++ runtime that is not C++ compatible in memory/resource usage is fatal. Weasel its about time you stop pushing myth that you can just use any C memory allocation API form C++ because you cannot do this. Same reason why Microsoft says do not mix C++ runtime versions where possible is the some of this is the same reason why mixing C with C++ can be deadly Weasel.

STOP LINKING SHIT WITHOUT UNDERSTANDING WHAT IT SAYS. You're digging that hole like always.

Nothing you linked has anything to do with what I said. In fact, it proves me right even more. It's literally beginner's level information about them.

C++ using malloc/free (C APIs btw) COMPILE TO THE SAME FUCKING THING as a C compiler would using the same code. Use gcc.godbolt.org to check it for yourself, dummy.

But yea, it's "magic" to you. Linking shit that he has no comprehension of, has absolutely nothing to do with the topic, but thinks it proves him right.


If YOU use operator delete (C++) on a malloc'd memory it's YOUR fault (and C can do it too), just like it's your fault if you use free() on a HeapAlloc (on Windows, it's a windows allocation API), both are C APIs btw.

It has nothing to do with the language, just the API. Mixing API for same allocation is bad, but you can use one API in either C or C++ for one part, another for another part, as long as the proper free is called for the respective allocation.

HeapAlloc->HeapFree
malloc->free
operator new->operator delete

It's that simple.

[Barnacle]

https://wiki.osdev.org/Rust

Rust has already done the small hobby OS stage. This has shown superiority to all the normal and abnormal program language choices for making OS in.

Absurd and highly biased conclusion, but sure.

If you are asking the question what is the program language that will take the least amount of time to write a stable OS from scratch with our current list of program language the answer is rust. This is proven out by the OS that have been written in rust and how little time they in fact have taken to get to particular stages.

C is the only language that properly separates the standard library from the core language, which is why it is so massively successful in the OS kernel space. That and the fact that C addresses everything as thin abstraction layers over raw bits and bytes. OS kernels cannot, themselves, use the standard library for their language, because the standard library relies on the kernel for things like memory allocation.

Imagine re-implementing most or all the Rust or C++ standard libraries in the kernel, using kernel memory allocation techniques, just to have the "normal" language. It basically devolves back down to C, but with extra rules not use certain language features, and more heavyweight syntax gymnastics to cut through the thicker abstraction layers. C is simple and direct without any guesswork as to what would result in a memory allocation, which really, really matters when you are developing an OS kernel.

Please note I am not saying rust is all good. Rust integrate into existing OS based on C or C++ not as simple as one would hope for. Rust limited compiler support is another big problem that is starting to be addressed.

You asked for application people have written OSs. This kind of explains Linux kernel interest in rust.

The POSIX standard explicitly states that a UNIX operating system is written in C, and everything in the standard relies on this foundation. If the Rusties think they are such brilliant computer scientists, why not all focus all of your efforts on one of those new/modern/trendy/whatever non-POSIX Rust-based kernels? It should be the greatest OS that ever existed, right? Then everything in it will be secure/stable/fast/awesome/whatever, and Windows can finally be de-throned. Just imagine if all of these "Pacman, but in Rust!" projects and non-POSIX Rust kernels all coalesced into a single distro? It should finally prove that Rust is the computing revolution it's fanboys say it is.

[oiaohm]

Imagine re-implementing most or all the Rust or C++ standard libraries in the kernel, using kernel memory allocation techniques, just to have the "normal" language. It basically devolves back down to C, but with extra rules not use certain language features, and more heavyweight syntax gymnastics to cut through the thicker abstraction layers. C is simple and direct without any guesswork as to what would result in a memory allocation, which really, really matters when you are developing an OS kernel.

No you did not look at hobby rust OS example did you. Rust standard libraries are not required to use rust memory management. Linux kernel has sparse and other checking does because for OS development so your OS does not crash all the time you need to use memory correctly. Rust borrow checker is a static Analysis tool. Rust language makes sure programmer puts in different annotation so that static analysis tool can make sane reports to programmer when they have coded something wrong.

The POSIX standard explicitly states that a UNIX operating system is written in C, and everything in the standard relies on this foundation. If the Rusties think they are such brilliant computer scientists, why not all focus all of your efforts on one of those new/modern/trendy/whatever non-POSIX Rust-based kernels? It should be the greatest OS that ever existed, right? Then everything in it will be secure/stable/fast/awesome/whatever, and Windows can finally be de-throned. Just imagine if all of these "Pacman, but in Rust!" projects and non-POSIX Rust kernels all coalesced into a single distro? It should finally prove that Rust is the computing revolution it's fanboys say it is.

No POSIX standard does not say Unix operating system has to be written in C. There are a few certified unix operating systems written in ada and other non C operating systems for the OS kernel. Rust is no different here.

[oiaohm]

STOP LINKING SHIT WITHOUT UNDERSTANDING WHAT IT SAYS. You're digging that hole like always.

Nothing you linked has anything to do with what I said. In fact, it proves me right even more. It's literally beginner's level information about them.

C++ using malloc/free (C APIs btw) COMPILE TO THE SAME FUCKING THING as a C compiler would using the same code. Use gcc.godbolt.org to check it for yourself, dummy..

I quoted a particular thing. As expect here is weasel going of with a total tangent of wrong.

There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls.
Read this again. Do you use free/malloc with gcc implication-defined behaviors like alignments. There was nice conflit in 2016 between gcc c generation of alignment malloc vs gcc C++ generation of alignments on malloc result in C++ incompatibility yes that still part of gcc if you use the right options.

Weasel you need to learn to read here I went to the effort of quote the line in bold. There was something very important in that line. Implementation defined behavior gcc 99% of the time will do malloc/free the same with C and C++ but there that 1 percent wire you use gcc implementation-defined behaviours were it does not.

Yes there are performance optimizations in C that a C programs can have done that when you build that program with C++ compiler will be ignored. Mixing C and C++ is not as safe as fools like Weasel makes out. If a C library includes the extern "C" wrappers in it headers it should not have used any option that is C only at least for the items it exporting. Those wrappers being missing is a hear be dragons warning that sooner or latter you get bitten by.

[Weasel]

I quoted a particular thing. As expect here is weasel going of with a total tangent of wrong.

There is a range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls.
Read this again. Do you use free/malloc with gcc implication-defined behaviors like alignments.

The behavior is the same if you call it from C or C++, even the generated code is the same.

So what the fuck is your point?

[oiaohm]

The behavior is the same if you call it from C or C++, even the generated code is the same.

So what the fuck is your point?

Read what I wrote again. "Do you use free/malloc with gcc implication-defined behaviors like alignments."

I gave a very particular note in the past post. You foolishly did not check it Weasel.Gcc C and C++ don't handle alignments always the same. So malloc with alignment value set built as C and C++ with gcc in fact can generate different code. __attribute__((aligned( ))) is a fun source of gremlins between C and C++ code with gcc.

https://stackoverflow.com/questions/48068142/gcc-and-g-struct-packing-differences

Then like the above struct packing is also different between C and C++. By the way defining extern "C" does not make sure that C++ complier does not decide to use C++ structure packing instead of C structure packing.

C and C++ have quite a few incompatible points. Weasel most of the time C libraries avoid these evils. But there are exceptions to the rule.

[Weasel]

Read what I wrote again. "Do you use free/malloc with gcc implication-defined behaviors like alignments."

I gave a very particular note in the past post. You foolishly did not check it Weasel.Gcc C and C++ don't handle alignments always the same. So malloc with alignment value set built as C and C++ with gcc in fact can generate different code. __attribute__((aligned( ))) is a fun source of gremlins between C and C++ code with gcc.

They do. They compile to the same code.

Show me code where C++ behaves differently with alignment. You can use gcc.godbolt.org to post the results, I can read assembly code.

https://stackoverflow.com/questions/48068142/gcc-and-g-struct-packing-differences
Then like the above struct packing is also different between C and C++. By the way defining extern "C" does not make sure that C++ complier does not decide to use C++ structure packing instead of C structure packing.

C and C++ have quite a few incompatible points. Weasel most of the time C libraries avoid these evils. But there are exceptions to the rule.

Only empty structs have that problem, and now you have a C++ attribute for those, [[no_unique_address]].

But a struct's layout has nothing to do with malloc/free lol, since you're calling the same API. And you're using it in C++, so the struct differences are irrelevant.

Empty structs are an example where you have to write a different header for C++. But it will still work, if you write it some other way (such as adding that attribute), just needs to be written differently. But it will compile to the same thing.