Readit News logoReadit News
accelbred commented on C and Undefined Behaviour   lelanthran.com/chap14/con... · Posted by u/lelanthran
nrds · 4 days ago
Is it even worth pointing out that the author misunderstands how UB works in Rust, given that at this point such a misunderstanding has to be willful than otherwise? There is _no_ UB in the safe subset of Rust, and in mixed safe-unsafe rust, the UB can only originate in the unsafe blocks.

In modern C++ (i.e. with smart pointers) something similar is true in that the UB can only occur in code dealing with certain types and functions (e.g. raw pointers), and not other types and functions. It's really the same as rust, just without the compiler support and the explicit unsafe blocks.

accelbred · 4 days ago
I think you are entirely missing the author's point. The author is generalizing from the specific technicalities of C/Rust/etc UB, to the problem with UB which is that should it be triggered, then you can't know what the program will do. This does not have to be the result of language specification. If writing safe Rust yourself, yes no UB will occur usually, and you can know what will happen based off of what code you wrote. The author extends UB to vibecoding where there is no specification to understand the translation of prompts to code. Without thorough review, you are unable to be sure that the output code matches the intent of your prompting, which is analagous to writing code with UB. The issue the author has with vibecoded Rust is not that the code can trigger undefined behavior at the language layer, but that the perfectly "safe" code generated may not at all match the intended semantics.
accelbred commented on Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust   github.com/j178/prek... · Posted by u/fortuitous-frog
jdxcode · 9 days ago
the second the hooks modify the code they've broken your sandbox

I think wasi is a cool way to handle this problem. I don't think security is a reason though.

accelbred · 9 days ago
I wouldn't want hooks modifying the code. They should be only approve/reject. Ideally landlock rules would give them only ro access to repo dir
accelbred commented on C Is Best (2025)   sqlite.org/whyc.html... · Posted by u/alexpadula
oconnor663 · a month ago
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.

I think there are effects in both directions here. In C you get burned, and the pain is memorable. In Rust you get forced into safe patterns immediately. I could believe that someone who has done only Rust might be missing that "healthy paranoia". But for teaching in general, it's hard to beat frequent and immediate feedback. Anecdotally it's common for experienced C programmers to learn about some of the rules only late in their careers, maybe because they didn't happen to get burned by a particular rule earlier.

> Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment.

This is an interesting contrast to the previous case. If you write a lot of unsafe Rust, you will eventually get burned. If you're lucky, it'll be a Miri failure. I think this makes folks who work with unsafe Rust extremely paranoid. It's also easier to sustain an that level of paranoia with Rust, because you hopefully only have to consider small bits of unsafe code in isolation, and not thousands of lines of application logic manipulating raw pointers or whatever.

accelbred · a month ago
The amount of paranoia I need for unsafe Rust is orders of magnitudes higher than C. Keeping track of the many things that can implicity drop values and/or free memory, and figuring out if im handling raw pointers and reference conversions in a way that doesn't accidentally alias is painful. The C rules are fewer and simpler, and are also well known, and are aleviated and documented by guidelines like MISRA. Unsafe Rust has more rules, which seem underspecified and underdocumented, and also unstable. Known unknowns are preferable over unknown unknowns.
accelbred commented on Rust--: Rust without the borrow checker   github.com/buyukakyuz/rus... · Posted by u/ravenical
adastra22 · a month ago
…then just use Rust? I’m confused. Most of this stuff never comes up if you aren’t doing things where memory safety would be an issue.
accelbred · a month ago
The code I have in C is often code that does't fit in Rusts safety model. Dealing with ffi is annoying because slices have no defined layout. `dyn` is limited compared to what I can do with a manual vtable. I have seriously attempted porting my personal stuff to Rust, but theres enough papercuts that I go back to C. I want the parts of Rust I find to be helpful without those parts I don't.
accelbred commented on Rust--: Rust without the borrow checker   github.com/buyukakyuz/rus... · Posted by u/ravenical
giancarlostoro · a month ago
I've been wishing for Rust to become more ergonomic, what ergonomics does Rust currently have that other languages lack?
accelbred · a month ago
For me its everything being an expression, macro_rules, dyn, automatic conversions (the few that it does have), traits, and the ? operator.
accelbred commented on Rust--: Rust without the borrow checker   github.com/buyukakyuz/rus... · Posted by u/ravenical
accelbred · a month ago
I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.
accelbred commented on Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers   phoronix.com/news/Meta-SC... · Posted by u/yellow_lead
bigyabai · 2 months ago
I mean, part of it is that Linux's default scheduler is braindead by modern standards: https://en.wikipedia.org/wiki/Completely_Fair_Scheduler
accelbred · 2 months ago
CFS was replaced by EEVDF, no?
accelbred commented on Linux Kernel Rust Code Sees Its First CVE Vulnerability   phoronix.com/news/First-L... · Posted by u/weinzierl
mustache_kimono · 2 months ago
> So the prediction that incautious and unverified unsafe {} blocks would cause CVEs seems entirely accurate.

This is one/the first CVE caused by a mistake made using unsafe Rust. But it was revealed along with 159 new kernel CVEs found in C code.[0]

It may just be me, but it seems wildly myopic to draw conclusions about Rust, or even, unsafe Rust from one CVE. More CVEs will absolutely happen. But even true Rust haters have to recognize that tide of CVEs in kernel C code runs something like 19+ CVEs per day? What kind of case can you make that "incautious and unverified unsafe {} blocks" is worse than that?

[0]: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

accelbred · 2 months ago
The kernel policy for CVEs is any patch that is backported, no? So this is just the first Rust patch, post being non-experimental, that was backported?
accelbred commented on Interview with Kent Overstreet (Bcachefs) [audio]   linuxunplugged.com/644... · Posted by u/teekert
accelbred · 2 months ago
As far as I can tell, the only missing feature for me to try to switch to bcachefs is fs-verity.
accelbred commented on It seems that OpenAI is scraping [certificate transparency] logs   benjojo.co.uk/u/benjojo/h... · Posted by u/pavel_lishin
accelbred · 2 months ago
Seems like you could set up a cert for a honeypot domain to collect ips of bots running off of the certificate transparency logs. If domain isnt linked from anywhere, then its pretty sure to be a bot isn't it?

u/accelbred

KarmaCake day396November 4, 2018
About
archit@accelbread.com

This account is accelbred because I lost the password to accelbread...

View Original