261–270 of 277 posts
Earlier quoted context omitted.
What clashes?
I think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.
Earlier quoted context omitted.
I think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.
“The rust people” were also kernel maintainers.
Intentionally or not, this post demonstrates one of the things that makes safer abstractions in C less desirable: the shared pointer implementation uses a POSIX mutex, which means it’s (1) not cross platform, and (2) pays the mutex overhead even in provably single-threaded contexts. In other words, it’s not a zero-cost abstraction. C++’s shared pointer has the same problem; Rust avoids it by having two types (Rc and…
Earlier quoted context omitted.
“The rust people” were also kernel maintainers.
Sorry, I'm not familiar with the titles of kernel developers. I thought only one of them was the subsystem maintainer.
Earlier quoted context omitted.
Yup. And I like the implication that Rust is 'cross platform', when it's 'tier 1' support consists of 2 architectures (x86 & arm64). I guess we're converging on a world where those 2 + riscv are all that matter to most people, but it's not yet a world where they are all that matter to all people. [1] https://doc.rust-lang.org/beta/rustc/platform-support.html
You are misunderstanding what Tiers are. Embedded architectures cannot be Tier 1 which requires running Rust compiler compiled on the architecture itself and testing stuff on with it. Only full desktop systems will be Tier 1, because those are the systems that you can run Rustc and all the nice desktop environments. However most of the embedded world uses ARM chips and they are Tier 2 like thumbv6m and thumbv7em (the…
However most of the embedded world uses ARM chips
My point exactly.
Earlier quoted context omitted.
If you want to return some precalculated stuff w/o using malloc() free(). So you just have 8 preallocated buffers and you rotate them between calls. Of course you need to be aware that results have short lifetime.
That sounds like a maintenance nightmare to me. If you insist on static, I would at least only use one buffer, to make it predictable, but personally I would just let the caller pass a pointer, where I can put the data. What application is that for? Embedded, GUI program, server, ...?
Yes, you should never ever use it in Library.. But small utility functions should be okish :)
This is example from my Ruby graph library. GetMouseEvent can be called alot, but I need at most 2 results. Its Ruby, so I can either dynamicaly allocate objects and let GC pickup them later, or just use static stuff here, no GC overhead. it can be called 100s of times per second, so its worth it.
static GrMouseEvent evs[8];
static int z=0;
GrMouseEvent *ev=&evs[z];Earlier quoted context omitted.
The number of times I might want to write something in C and have it less likely to crash absolutely dwarfs the number of times I care about that code being cross-platform. Sure, cross-platform is desirable, if there's no cost involved, and mandatory if you actually need it, but it's a "nice to have" most of the time, not a "needs this". As for mutex overheads, yep, that's annoying, but really, how annoying ? Modern…
> There's simply too much out there written in C to say "just use Rust, or Swift, or ..." - too many libraries, too many resources, too many tutorials, etc. There really isn't. Speaking as someone who works in JVM-land, you really can avoid C all the time if you're willing to actually try.
Plus, a lot of what I do is on microcontrollers with tens of kilobytes of RAM, not big-iron massively parallel servers where Java is commonly used. The vendor platform libraries are universally provided in C, so unless you want to reimplement the SPI or USB handler code, and probably write the darn rust implementation/Java virtual machine, and somehow squeeze it all in, then no, you can’t really avoid C.
Or assembler for that matter, interrupt routines often need assembly language to get latency down, and memory management (use this RAM address range because it’s “TCM” 1-clock latency, otherwise it’s 5 or 6 clocks and everything breaks…)
Earlier quoted context omitted.
True, but that's a fault of the implementation, which assumes POSIX is the only thing in town & makes questionable optimization choices, rather that of the language itself (for reference, the person above is referring to what's described here: https://snf.github.io/2019/02/13/shared-ptr-optimization/ )
> the language itself The "language" is conventionally thought of as the sum of the effects given by the { compiler + runtime libraries }. The "language" often specifies features that are implemented exclusively in target libraries, for example. You're correct to say that they're not "language features" but the two domains share a single label like "C++20" / "C11" - so unless you're designing the toolchain it's not a…
Earlier quoted context omitted.
I wrote "multithreaded" but I really meant "multicore". If two cores are contending for a lock I don't see how irq protection help. As long as there is only one core, I agree.
On most multicore systems you can pin the IRQ handling to a single core. Pinning locking interrupts to a single core would be how you handle this.
I feel like there might be some value in this header file for some projects, but this is exactly the wrong use case. > In cgrep, parsing command-line options the old way is a breeding ground for CVEs and its bestiary. You have to remember to free the memory on every single exit path, difficult for the undisciplined. No, no, no. Command line options that will exist the entire lifetime of the program are the quintessen…
There are (older) OSes where this is NOT the case. Leaving things un-freed would leak memory after the application has terminated.