MaulingMonkey · HackerTrans

MaulingMonkey

4,349 カルマ登録 13 年前

Engine Programmer.

http://maulingmonkey.com/

コメント

9 時間前議論

I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them:

• `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`.

• `std::env::set_var(...)`. It's now marked `unsafe`. While I dodged the bullet, these fellows didn't: https://www.geldata.com/blog/c-stdlib-isn-t-threadsafe-and-e...

• `#[no_mangle]`. It's now `#[unsafe(no_mangle)]`.

I don't believe I've constructed cvs-rs's hole by accident. cve-rs's code links to https://github.com/rust-lang/rust/issues/25860 , which is admittedly still open after a decade. Progress appears to still be ongoing though! Related:

• https://github.com/orgs/rust-lang/projects/44/views/1

• https://rust-lang.github.io/rust-project-goals/2025h2/next-s...

> Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: [...]

Thanks for sharing a concrete example of Fil-C's limitations! Disappointing - but not unexpected - to see it underperforming existing sanitizers. I was hoping for better.

昨日議論

> If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.

Just write `#![forbid(unsafe_code)]` at the top of your src/lib.rs, and track crates not using it with `cargo geiger`. You don't need a whole new language, it already provides the tools to wield that hatch shut.

> Rust is less safe because it has a feature for turning off safety

Can I write Fil-C's mmap wrapper in Fil-C?

If no, fair enough, but it's worth noting I can write a safe Rust mmap wrapper in Rust, and I absolutely and frequently need to do that kind of "syscall wrapping" in arenas Fil-C explicitly hasn't handled, by virtue of being explicitly a Linux project.

If yes, that sounds like an escape hatch to Fil-C's memory safety, undermining the claim that Fil-C is fundamentally safer, and you're now at best arguing it's safer as tends to be used.

9 日前議論

I adore unsafe, appreciate it as a feature... but it is an escape hatch. One that is sometimes necessary, one that is sometimes not necessary but might still be (ab)used for performance, or initial 1:1 porting of C/C++ code. There are a lot of cases where that escape hatch should probably welded shut though. Fortunately, the Rust ecosystem has tools like `cargo geiger`, and straight out of the box I can also write:

    // src\lib.rs
    #![forbid(unsafe_code)]

20 日前議論

> The myth of DNS “propagation” needs to die.

What's the actual issue? Are you being frustrated by people laboring under the assumption that DNS records are being sent by carrier pidgeon or something?

> There is no geographical connection whatsoever.

DNS censorship will presumably be based on geopolitical boundaries, which in turn are bound by geography. And I wouldn't be entirely suprised if poor network connections - including those potentially geographically bound (poor weather / flooding / tornados severing or degrading links or power) had some (minor, infrequent) impact on the rate stale cache entries are evicted in favor of fresh ones.

Granted, none of that means a DNS resolver halfway across the globe from the authoritative servers can't typically get updated results <200ms (≈light speed), which is safely ignorable / won't be visible as records propagating from geographic neighbor to geographic neighbor. And granted further, I'm both too boring to censor, and too smart to be on call for anything that would make me aware of global outage reports - so the map is admittedly useless to me beyond farming that hacker vibe aura.

But I imagine there's at least one or two dudes out there that'll see a red dot in, say, Australia - and that'll save them a few minutes, by giving them a shortcut to determining the root cause of some issue reported in Australia by letting them correctly guess/blame stale DNS records.

先月議論

> Will programmers write more efficient code during the memory shortage?

Yes. No. Yes.

I've worked in gamedev, helping ship code that ran on consoles. Nice fixed hardware targets. You OOM, you crash. We crashed a lot, and cut and saved and optimized and explicitly invoked the garbage collector twice on level transitions, because a single full scripting language GC doesn't work when finalizers must run to deref C++ objects to unroot script objects, and committed other horrific hacks.

The memory shortage may eventually impact fixed targets like this. Or the minspec publishers will swallow for fuzzier targets like "PC". But it takes awhile for new targets to roll out, and for newly bought PCs to make a significant dent on total percentage of PC ownership. Steam Machine's about to release with 16+8GB and while price and market saturation may be affected by the memory shortage, I'd be suprised if the actual spec changed.

> Maybe there will even be more interest in the invention and use of more advanced algorithms

Not for typical gamedev IMO. There the focus will be more on "reduce the amount of content loaded in memory simultaniously". That means less detail, smaller scale, or less variation. Going from 4096x4096 to 2048x2048 textures quarters your texture memory usage. The surface of meshes also has some square density nonsense going on. Basic animation tends to scale with bone count and keyframes, which are more linear, although shape keys are more per-vertex nonsense.

And of course, reusing the same mesh or texture multiple times doesn't use more memory, just more memory bandwidth.

Audio is more a factor of "how many sound effects (and variants) do we need preloaded just in case there's suddenly an event that triggers them".

These are the big ticket items for memory use and advanced algorithms don't help much. Rather, the algorithms help stretch whatever amount of memory you do have to provide the best amount of quality you can, and the small constant shift in total memory availability doesn't change the calculus for how important that is very much (which depending on the game ranges from "unimportant, everything fits in memory easily" to "critical, we're doing open world streaming and we've got terrabytes of raw data already, 16 vs 64GB of memory doesn't change that much")

> and data structures that use less memory?

Some bit packing type stuff comes up for smaller logical data structures in gamedev, and that can be useful for saving memory bandwidth, but I'm skeptical of how critical it is for total memory usage outside of the occasional Factorio.

先月議論

C++'s stdlib collection algorithms were basically all mutate-in-place instead of return-a-new-value until C++20 introduced ranges, and I still don't know anyone who actually uses those. By contrast, people actually use the `container.iter().map(...)` etc. in Rust.

C++ also lacks much of the fancy pattern matching features which are frequently associated with functional programming. Such features may not be fundamental to functional programming, but they would fall under "some functional programming features", in the sense that they're common in the languages of that ecosystem.

先月議論

> But you can learn to phrase your WTFs about your colleague's code politely and constructively. I would even argue that this an absolutely basic skill for professionals. It typically leads to faster and better answers whenever a discussion arises.

Phrasing things politely and constructively is what I'm explicitly advocating for when I'm calling for "tact", yes. But said phrasing is not necessairly the very first thoughts out of my mind. When we push back on sharing our raw thoughts, it's precisely because we want a moment to be able to translate from passionate, driven, and perhaps rude thoughts - to polite, if perhaps a bit professionally dispassionate words. From unconvincing incendiary moral judgements against the cult of the singleton, to concrete examples of maintainence concerns and tradeoffs that can be discussed by everyone. From things that barely make sense in the context of our own minds, to things communicated clearly within the context and bounds of our shared understanding.

> Even if confusion seems to spread in a discussion, I would expect the person who realizes this first to call that out and and to reset the conversation.

Simply calling out confusion is insufficient to resolve confusion. Being able to narrow down what I'm confused about is an important skill and first step towards either unconfusing myself, or seeking help from others, allowing them to aid me in solving said confusion.

Unconfusing others is a step more difficult. Unlike with my own confusion, I find it necessary to build an accurate mental model of their thought process through my own indirect observation and questions, to understand where they've misunderstood, the correct understanding, and then a means of explaining and contrasting those two states through nothing more than clear communication to bring them out of said confusion. I may have to construct full blown examples, showing a concrete way their own initial biases fail them.

These are important skills and steps to take, of course, and you're right that there's nothing magic about it, but this is something I've expended a lot of time on over the decades I've been puttering around in development circles. It's time intensive, requiring one or more people focusing on a single individual's issues, just to reset things to a baseline of being unconfused enough to do good work.

And, of course, it will always be necessary, and I'm glad to help. It's a skill I believe I'm good at, and by unblocking coworkers and friends, I can potentially spend minutes of my time to save hours or even days of theirs, which is well worth it. But it's also worth taking the time to avoid such scenarios coming up again. It saves me time, and it saves them time.

Sometimes that means clearing up ambiguous or confusing documentation.

Sometimes that means keeping others at arm's length - at least until I'm at least no longer confused about what exactly I'm confused about.

先月議論

I don't want the private API key I temporarily hardcoded in my public history. Nor do I want the drag of worrying about so much as sneezing in the general vicinity of a secret in my editor window, when I already self review before commit.

I don't want the unkind rant about a coworker's design as I attempt to figure out what they were smoking when they made the thing I'm trying to use, needlessly offending them. For starters, once it clicks, it might all make sense, and have turned out to be my mistake. For another, even if a rant is warranted, a pass for "tact", or at least limiting the blame to the blame that is warranted, is proper.

I don't want to drag a coworker through my chain of confusion until I've made an appropriate amount of effort to unconfuse myself first. To do otherwise is likely to bring us both to confusion, possibly in different ways, possibly including confusion about what we're confused about, which is just a mess and dead weight. There's a time and place to explain and teach, and a time and place to expose my own confusion and ask for help, but neither is step 1.

Even if the API is undocumented and confusing, even if you're expected to ask for help as step 1, there's value in a fresh set of eyes getting a feel for exactly how the API is confusing before that, thus informing directions for potential improvement (be that API changes or improved documentation.)

先月議論

I'll note that speedrunners absolutely buffer mid-pipeline in Factorio, and not just for hand-crafting purpouses. Sometimes you're waiting for R&D, sometimes you're just running half the machines for twice as long, giving you the same output while saving on build costs. The actual bottlenecks are constantly shifting. "I'm not speedrunning!" you might say, but every regular game could've started as a speedrun that could've gotten you to where you are faster.

Understanding the tendency of mid-pipeline buffers to hide problems is useful, but scorning them entirely is also suboptimal.

先月議論

> That's the point, std::byte is for opaque bytes. You're not expected to do arithmetic directly just like you can't do arithmetic on void.

That'd make a whole lot more sense to me if `std::byte` didn't explicitly implement a whole bunch of bit twiddling operations:

    << >> |= &= ^= | & ^ ~

This isn't opaque. This is a poor man's half-assed `std::bitset<8>` with a guaranteed `sizeof(std::byte) == 1`.

2 か月前議論

To be fair, the `void*` is already a pretty big hint that you're in the danger zone.

2 か月前議論

> if somewhere in the plumbing you connect the wrong source to the wrong destination, you get no warning.

A valid concern. I've been in the position of having to fix those bugs.

I'm not going to recommend `qsort` over `std::sort` or anything like that. I've seen `void*` "user data" pointers in C APIs and decided to stuff runtime checkable handle values in there instead of real pointers to blobs. In Rust, this can mean avoiding some unnecessary `unsafe { ... }` blocks, since while reading anything from a `*const c_void` requires such things, reading from a global `Mutex<HashMap<*const c_void, Arc<dyn Any>>>` or similar nonsense does not. I'll eat the performance hit unless I'm worrying about an actual hot path!

And I'm not going to stand in the way of newtype wrappers around void pointers either. I'll +1 the PRs with `class ASpecificKindOfBlob { void* data; size_t length; };` and suchlike as well, if `std::span`s aren't your type of thing, and abide by measures to centralize such plumbing in one place such that the opportunities to make a mistake are fewer.

But sometimes a blob is just a blob, and breaking out `std::byte` is putting lipstick on a pig. And it's not even the right color lipstick.

2 か月前議論

> Fair point (although to be honest: 'complexify' feels a bit of an exaggeration here to me)

Both uint8_t and std::byte require a header (<cstdint> or <cstddef>) which may expose you to platform x config specific build failures if you do any conditional #including, and the latter is a whole damn enum class with a strange adversion to arithmetic, where `byte |= 1` becomes `byte |= std::byte(1)`, `byte += 1` becomes `byte = std::byte(std::to_integer<std::uint8_t>(byte) + 1);`, and both become something you can accidentally step into in your full debug builds because it's an actual function call (at least on MSVC - still extra instructions on clang/gcc, but I can see the dang call instruction on MSVC!) instead of a compiler built in.

Not to mention, neither is vanilla C++03... I threw a `std::byte` example in a quick godbolt snippet and MSVC wouldn't compile without adding /std:c++17, because of course it defaults to earlier. Which is silly, but that's also the story of my life.

And don't get me wrong - that's all relatively minor - but it's all for middling to negative value IME. `void*` is frequently clearer - it's a signal that it's an opaque blob at this point in the code, and that something else will try to give it meaning later. I struggle to think of a single bug that I've encountered, that would've been caught by the compiler had I used `std::byte` over `unsigned char` or `void`. And conversely, I've seen APIs accepting `std::byte` but requiring higher alignment, where with `void` I might not have dropped my guard as much.

> `std::span`

At least manages to bind pointer and size into a single variable, which IME at least has the advantage of eliminating some bugs (e.g. mismatching pointers and sizes) and allowing some nifty utility functions to become a lot more wieldy. You can do things like feed it an array and not have to do any of your own `sizeof(...)` shenannigans. At this point you're possibly getting into positive expected value, but I'm going to eye roll at pull requests refactoring `void*` based stuff to use it unless I see at least one actual concrete example of calling code improving alongside it - I don't want just hypothetical theoretical ergonomics, I want actual concrete ergonomics!

2 か月前議論

TIL the horror that is the existence of non-serializable isolation.

I'm a gamedev. I've worked alongside webdevs (frontend and backend) that build our websites and forums. Alongside coworkers who handle networking stuff while I port things on the same project. Spotted SQLIs for people and pointed them on a better path [1]. I've dabbled in my own share of SQL-adjacent queries... which is to say databases have always been on my list of things I should probably take the time to put properly into my toolkit, for increased reliability and data durability. After all, rotating file snapshots by hand, and fuzzing formats to create recoverability from corruption (if only by detecting it and reverting to previous snapshots instead of crashing or corrupting further) is clearly the work of uncultured barbarians, bereft the wonders of proper fsync-aware ACID storage technologies.

And then I read this:

---------------------------------------------

However, many database vendors use weaker isolation levels by default, in particular:

• “Read committed” in PostgreSQL and Oracle.

• “Repeatable read” in MySQL/InnoDB (there is a subtlety, see below) in YugabyteDB.

---------------------------------------------

I regret the clearly undue respect and regard I've given to database technology. I knew some of this kind of nonsense had intruded with the NoSQL and sharding crowd, but I thought you at least had to ask for such ruination for most of the SQLs used in production, at least in the context of a singular database. Euhg.

1. https://blog.codinghorror.com/give-me-parameterized-sql-or-g...

2 か月前議論

> I disagree that you'll find "many red flags for any job"

If they're hiding the many red flags, that's the biggest red flag of all!

2 か月前議論

> If you're steeped deeply enough in that NDA-preserving culture

If you've throroughly absorbed a culture of honoring non disclosure agreements (NDAs), which are legal contracts demanding you keep secrets and avoid sharing sensitive data or code...

> a reminder that you've switched contexts might help

A reminder that rust-lang is a transparent, open source project, with no non-disclosure agreements or trade secrets to keep private unto itself might help [1].

> when common sense proves uncommon.

Because everyone misses the "obvious" sometimes. And because "obvious" is a subjective value judgement, meaning people will disagree what is or is not obvious.

-------

1. That said, if you've got a private, corporate-internal, closed source fork, you might still be bound by such concerns. For example, various people have ported rust's stdlib to work on various consoles (xbox, playstation, etc.) - and one of the reasons you don't see that upstreamed is because doing so would require violating console vendor NDAs, as well as possibly their company's NDAs - possibly for such banal reasons as not wanting to leak a hint of a console port or new title before their marketing plans are ready to go to capitilize on any hype.

2 か月前議論

> Like seriously, what's the point of explicitly allowing this?

Explicit permission can be useful to preemptively cut off some questions from well meaning people who, acting in good faith, might otherwise pester for clarification (no matter how silly / "obvious" it might otherwise be), or get agitated by misconstruing an all-banned list as being an overly verbose "no LLMs ever" overreach.

> It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: [...]

Many of us work or have worked in corporate settings where IT takes great pains to help detect and prevent data exfiltration, and have absolutely installed the corporate spyware to detect those kinds of actions when performed on their own closed source codebases. Others rely on the honor system - at least as far as you know - but still ban such actions out of copyright/trade secret concerns. If you're steeped deeply enough in that NDA-preserving culture, a reminder that you've switched contexts might help when common sense proves uncommon.

While nannying can be obnoxious, I'm not sure that having a document one can point to/link/cite, to allay any raised concerns, counts.

3 か月前議論

My trick: Walk to meals and other excursions/shopping in lieu of driving.

If I leave on a walk for the exclusive purpouse of "exercise", I immediately feel bored, and like I'm wasting time, even if I "know" I'm not. Conversely, if I have goals to achieve at a destination, cutting the walk short to drive - or cook at home - is no less boring, and feels like a waste of the walking I did do.

It started as a way to take a break from work when I was crunching, with the company of coworkers. They'd grab lunch, or coffee, and you might as well stretch your legs and socialize while you're at it.

3 か月前議論

My family accepts me just the way I am a bit too much. I can't bring myself to blame them, when past "reformist" pressures have been misguided/misapplied and backfired, but I recognize the trap. It'd also be hypocritical to blame them, when I also accept me just the way I am a bit too much! I'd like to think I'm decent enough to people, but I'm certainly more useless than I'd like to be. (Un?)fortunately, I'm not in a position to suffer, and I'm at least aware of the problem!

One of the ideas I've toyed with, even before all the AI hype, is a dumb, semi-adversarial servitor. Something to nag or taunt me about chores not done, to interrupt me when I'm doomscrolling, to use as a vessel for precommitment, to challenge me in various ways. I've been too lazy to build it thus far. Many tools overlap the problem space, so I shouldn't be using that as an excuse - perhaps I should give StayFocusd another shot.

Conflict and other stressors - in moderation, within the limits of one's ability to handle - are important for growth and health. A tree shielded from wind is weakened as it fails to develop stress wood and structural strength. A good debate can sharpen my thoughts and mind, walking to lunch keeps my cardiovascular system healthy, rising to life's various challenges gives me the security of knowing I can rise to the occasion and gives me more skills.

3 か月前議論

Trade is just a combination of give and take. I give you X, and in exchange, take Y. Without the "take", it's not a trade, it's just a gift.