uecker

1,969 karmajoined 6 năm trước

Computational Magnetic Resonance Imaging, Real-time Magnetic Resonance Imaging, GCC Contributor, BART Toolbox, Member of ISO C WG14

comments

18 giờ trướcdiscuss

A long time ago, I also thought one should use unsigned mostly but I am now in the opposite camp. Unsigned integers in C have semantics for modulo arithmetic. They are suitable if you need this, so for crypto, hashes, or if you only care about bits, etc. IMHO they should not be used for anything else. The reason is that it is very easy to screen for signed overflow bugs exactly because they have undefined behavior, just by turning on a sanitizer. It is also possible to transform overflow to safe traps at run-time where this is important. In contrast, finding unsigned wraparound bugs is extremely hard and can not be done automatically and preventing consequences of such bugs is difficult. Also any kind of index computation may have intermediate results that may be negative, so signed arithmetic is also generally more useful and far easier for people to understand and get right.

Hôm quadiscuss

Because it is not trustworthy, which is really the most important thing.

Hôm kiadiscuss

I do not keep track of them, but google finds CrateDepression, faster_log, async_println, finch-rust or recently: https://cybersecuritynews.com/supply-chain-trapdoor-malware/

It is not FUD as it is a real risk. cargo audit can only search for known issues, as such is like a virus scanner, often being too late. "You have to vet your dependencies no matter what" sounds nice, but Rust packages tend to pull in many hundreds of dependencies. But even for the comparable fewer dependencies in other languages, you can not usually vet everything yourself, you need to rely on the community to help. But then you need to have a curated software distribution, and this is exactly what traditional Linux distribution model does, while cargo does not.

xz scandal was a close call, but it was also a very sophisticated operation - which was then discovered by a Debian developer. This is not at all comparable to the cheap type squatting style attacks possible with cargo and confirms my point.

3 ngày trướcdiscuss

Of course, the point was that it is not a great step forward in software engineering but zig catching up to what was is a reasonable design.

4 ngày trướcdiscuss

I think there were enough attacks already for cargo that one can not call this FUD. It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.

The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

5 ngày trướcdiscuss

I would agree that the zig developers know what they are doing. But not necessarily all fans of the language...

6 ngày trướcdiscuss

It is exactly because software is a social activity that one should try to understand the purpose of a design before changing it.

6 ngày trướcdiscuss

Fair, but with all the new C-alternative languages I also see a lot of Chesterton's Fences being teared down. In part, this is also perfectly fine for experimentation, but sometimes it leaves me wondering as well.

6 ngày trướcdiscuss

On the other hand, systems like cargo a clearly a supply chain disaster.

I also think that languages should not have their own specific packaging system. This should be done on a distribution level, which provides curated lists of software. This system works well in the Linux world. The problem is the support for the commercial platforms.

The whole trend to think of programming languages as closed frameworks is bad. It is replacing a better system with one which is fundamentally much worse, instead of trying to fix the problems with the existing systems (which is hard because it needs collaboration and harmonization, instead of going into your own little bubble and pretending to do something superior).

7 ngày trướcdiscuss

It was a resounding endorsement in 2020, but the proof is in the pudding. So far I am not impressed. It is also not something I think is terribly important. Even if they managed to improve memory safety in the kernel using Rust (but I assume improvements in C tooling will have a much bigger impact), the reality is that for the overall Linux community (but maybe not Google and co.) others things would be far more important (such as a proper responsible disclosure process, the recent failures were pretty bad).

7 ngày trướcdiscuss

I wonder whether the "replacing c in the linux kernel" is not more wishful thinking by Rust enthusiasts. As of know it has less than 1% and less than bash.

8 ngày trướcdiscuss

Rust isn't perfect, this is my point. But its marketing is based on this idea ("rule out whole class of bugs"). If this were true then the bugs I cited could not exist, so they severe as counter examples that clearly invalidate this exaggerate claim. So we are back to the question to much incremental improvement it brings. The arguments you bring are essentially the same we heard before for object-orientation and other ideas. I agree that compiler enforcement helps, but the idea that this is a game changer is wrong.

I don't quite trust google's numbers and there are so many ways this could be biased. It is also not based on a comparison to modern C. One also has to realize how incredibly large the amount of C code is, which exists and with a lot also being very old and neglected. Any kind of CVE counting is highly misleading if you compare a new language with a security focus against existing projects. With more Rust code we will see more issues, especially when more average programmers use it that cut corners once they need to get things done. But I agree that this is where Rust can improve the situation, but so can modern C tooling. Wanting to put everything into the type system is a trend, but I don't think it is obviously the right step in the long run.

8 ngày trướcdiscuss

I think Rust helps a lot for people who would other struggle because they would otherwise create a mess by enforcing certain high-level structure that rules out certain problems. But you can just use very similar structures yourself in C programs! You can prevent problems in C as well by construction, even when the compiler does not enforce it. Often you can build data types where the interfaces enforces it. And my C programs also usually work on first try! I do not have to switch to another languages to experience this.

Sure, compiler enforcement can help, but the advantages of it are massively exaggerated. The "stuck in the past" narrative I heard very often, with OO, with managed languages, etc. I would say that Rust goes in the wrong direction with monomorphization and with safe but too rigid and simplistic rules.

And the "never seen level of correctness". Just look at some of the bugs found in Rust, it is just the same old nonsense as everywhere. The favorite bug I use as an example is this: https://github.com/advisories/GHSA-5gmm-6m36-r7jh A language where you can get the trivial check for the dimensions of a matrix transpose wrong just like in C is not at another level of correctness. Or the famous cloudflare bug where some unhandled .unwrap brought the whole internet down. That you theoretically can prevent all this with the type system is great, but IMHO misses the point.

9 ngày trướcdiscuss

Most of this can be done just fine in practice. NULL safety is not so much an issue as people claim as trapping is safe on most implementations and then similar to a panic in other languages. If you create data types via constructors you can then make sure those are initialized. Yes, this is a convention but easy to check. The const issue is not a problem IMHO. If you violate type safety yourself then this comparable to using escape hatches in other languages. Only the never-leave-this-thread point is something where Rust truly has an advantage, but one can have abstract data types that are thread-safe in C.

This is why I think a book is missing, people think C is much worse than it is because they do not understand what can be achieved.

10 ngày trướcdiscuss

C is a tool which requires expertise but then goes out of your way and let's you do things, and do things rather efficiently, with no overhead, and exactly how you want. If you want it to cut off your arm it will do this too. But if you want to abstract things away behind types, this can also be done too (and arguable should be done more often in C). Somebody should write a C to more modern and safe C migration book.

10 ngày trướcdiscuss

This is about as correct as saying http is bloated because there are printer protocols using REST.

12 ngày trướcdiscuss

It is amazing. It is the result of two decades of research in image reconstruction algorithms. The machine learning is part of it, but that it is sold as "AI" has probably more to do with marketing.

12 ngày trướcdiscuss

Reimplementing everything is not an option in C. But one should be able to pass string views directly to printf.

The allocating version is what string_dup does. strv2cstr is certainly more dangerous. But as since the size is encoded in the return type, compilers can add bounds checking (and partially already do so).

12 ngày trướcdiscuss

Without this flag it can also attach to existing processes and on my Debian this is set to zero.

12 ngày trướcdiscuss

It will not add one if there isn't one already. (I should probably rename this function, work in progress..). But the type is an array of the correct length.

Edit: renamed to strv2array