NobodyNada

> There's no standard terminology I'm aware of to distinguish the two.

There is: implementation-defined behavior. Your example of writing to an MMIO address is such an example, as the standard says casting an int to a pointer is implementation-defined. (However, the C standard has plenty of cases of undefined behavior that probably should have been implementation-defined.)

The list archive link seems to 404, but this one works: https://febo.com/pipermail/time-nuts_lists.febo.com/

You cannot write a type which conditionally implements Drop: https://play.rust-lang.org/?version=stable&mode=debug&editio...

    struct Q<T>(Option<T>);

    impl<T: 'static> Drop for Q<T> {
        fn drop(&mut self) {}
    }


    error[E0367]: `Drop` impl requires `T: 'static` but the struct it is implemented for does not
     --> src/main.rs:3:9
      |
    3 | impl<T: 'static> Drop for Q<T> {
      |         ^^^^^^^
      |
    note: the implementor must specify the same requirement
     --> src/main.rs:1:1
      |
    1 | struct Q<T>(Option<T>);
      | ^^^^^^^^^^^

That's incorrect; the compiler drops q before l. Drops happen in LIFO order; and the compiler knows that it can't drop l before q has been dropped, because q contains a reference to l.

The issue is that the destructor of q can observe a reference which is about to be deallocated as having a 'static lifetime (i.e. it will live forever), and can thus stash it away somewhere for other code to access after it's been freed (as in the examples in the issue which demonstrate UB.)

The error is the destructor of `q` could look at the reference and stash it away somewhere, like a global variable (since the compiler thinks the reference is valid forever). Then, some other part of the program could access that variable and cause a UAF.

I'm not familiar with Splint, but my understanding is that the error is because of the @only@ marker indicating that the string is not shared. That's an incorrect translation of the Rust program, where the reference to the string is explicitly a shared reference rather than an owned reference. The issue isn't the sharing; it's that rustc mistakenly allows the code to assign a reference that is valid until the end of the current scope to a field that expects a reference valid forever (like a string constant in the program binary). The Rust program with equivalent semantics to your C program (passing an owned String instead of a shared reference) is correctly rejected by the compiler.

Also, the Q_free function should not free q->t. It may access it (e.g. printing it), but it does not own that reference and is not responsible for deallocating its memory.

Sorry, I should have looked closer the first time! My excuse is that it was too early in the morning to be thinking about such things.

If you wrote a Q_free function and called it after `free(l);` to actually demonstrate the UAF, that would be pretty close to the semantics of the Rust example.

> Perhaps the better thing to focus on is the frequency of underruns (or "xruns" as they say on Linux, which also covers overruns) for a specific sample rate and buffer size setting.

Right, that's what I meant. There will be some jitter depending on the scheduler, system load, network performance and traffic, and the quality of hardware/drivers; so more latency gives you headroom to absorb the jitter without underruns. The "ideal configurations" I was referring to were the low-traffic network and high-quality NIC. On a setup with more jitter, you might have to increase the buffer size (and thus latency) for reliable operation.

Mostly, I was just trying to contextualize the numbers for readers who aren't super familiar with low-latency audio networking. Sure, this project may not achieve the sub-1-ms roundtrip latencies that you can get with dedicated Dante hardware (like a Yamaha mixer and stagebox); but Dante can't do better than 8ms when one of the ends is a PC (although they were probably aiming for reliability on setups not aggressively tuned for minimum jitter.)

The choice of port wasn't the complaint so much as the choice of IP address. 12.12.12.10 is a real IP address on the Internet, so if you plug this device in somewhere with an Internet connection, it will begin spamming nuisance traffic to some random device out there. It would be better to choose an IP address in one of the private spaces for this purpose.

See, for example, Cloudflare's stories of issues caused by misconfigured systems appropriating the "1.1.1.1" address for their own purposes: https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-g...

> The typical default latency for a Dante audio device is 1 msec.

(emphasis mine)

The latency depends on the device. Hardware implementations of Dante commonly support latencies of 1ms or less, but software implementations are higher. The minimum latency of Dante Virtual Soundcard running on a PC is 4ms.

That's the appropriate number to compare against here (since the PC is using a software driver to interface with the network). However, that 4ms number is one-way latency, and the OP's 3.6ms number is round-trip. So this is already half the latency of DVS. (That being said, it sounds like this latency figure was only achieved in very ideal configurations, and we don't know the reliability/rate of late packets compared to DVS.)

It's a common intentional misspelling/euphemism: https://knowyourmeme.com/memes/commit-sudoku

> However, rust has got to get their allocators for container support straightened out soon

Good news: https://github.com/rust-lang/rust/pull/156882

The allocator API has been stabilized, to be released in Rust 1.100 in November. (Though only Vec and Box will support custom allocators immediately; the rest of the standard library collections are coming later.)

Surely tape saturation or the artifacts/tone coloring of vinyl records would have been a better example.

Sounds like they can afford elite customer support.

Honda's hybrids are their own thing. They're mostly-series hybrids with one or two direct-drive gears for cruising speeds, as opposed to Toyota's parallel hybrid system.

I think my biggest issue with that is that people who just want to replay a game in a fresh way once or twice aren't the kind of people who are going to stick around and form a community; and those communities are what foster the creativity which brings freshness and depth to the games. I see it as quite similar to AI music creation, which, sure, allows people access to music that didn't exist before without putting in the effort, but in doing so it replaces what has historically been a community endeavor with a highly individualist, consumerist one.

My perspective is biased by the fact that such communities are an important part of my life. I don't want to see my years-long collaborations and friendships made obsolete by someone looking for an afternoon of nostalgia. And maybe everything will be fine, and the AI-users and the community-builders will go their separate ways and leave each other alone. But communities which exist today are having to ask how we should relate to AI, and my conclusion is that it's best kept out of hobbyist spaces if we want those spaces to continue to exist.

> Can you imagine a human sitting down and documenting a million lines of decompiled code from a dev team 20 years ago?

Yes: https://patrickjohnston.org/bank/index.html

> AI allows players to have decompiled and in turn ports of games to new platforms, enhanced versions of the game, etc.

To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so. The knowledge and intuition you learn about how computers really work; the friendships you develop through collaboration with others, through asking for help with your projects and helping others with theirs; and the relaxing Saturday afternoons spent investigating and debugging and experimenting. The "benefit" of having a game that's been recompiled to a native executable for your PC or whatever is marginal compared to the benefit of the process to get to that point. That end goal is just a lighthouse to keep you on track, and when you get there maybe you'll play the recompiled game once to celebrate a job well done before moving on to another project.

If writing software is a means to an end, then there's value in anything that reduces the effort to get to that end. But as I see it, retro gaming projects are mostly an end to a means.

> Seems pretty egoistical when nobody's forcing you to use AI in any way, it provides an objective benefit to other people.

I have three fundamental claims:

- There is little to no positive benefit to using AI for hobby projects whose completion provides little to no intrinsic value.

- Choosing to do so has a negative impact on you, as it bypasses an incredibly valuable learning experience.

- Choosing to do so has a negative impact on others, as it takes away someone else's project opportunity (there are a finite amount of popular retro games, and many people prefer to work on novel projects rather than recreating something that has already been done).

I'm not sure what's "egoistical" about that, and I'd love if you could elaborate on that because I'm still wrestling with the ethics and implications of all this myself. The way I see it, it's better if I choose to forgo the use of AI on my projects, and I think others should choose the same.

---

Many years back, one retro gaming community I'm a part of had a prolific contributor who was extremely knowledgeable about the game, but also incredibly abrasive. He was the most knowledgeable person in the community at the time, and held this over others; discrediting their achievements, discouraging their attempts to learn, constantly starting fights and driving many good people out of the community. Yet he was allowed to remain in the community for many years, because everyone thought we needed his expertise.

Eventually the community came to the realization that it's just a video game and we don't "need" anything at all. None of the long-term community members are really here for the game anymore; we're here for the experience and the camaraderie. So we should make decisions (like kicking out this member) that are technically suboptimal for the game (at least in the short term), but better for fostering the community.

In a similar vein, using AI within these sorts of hobby spaces may allow faster progress on such projects, but it takes away the value of completing the projects in the first place, to the detriment of both the individual and the community.

As someone heavily involved in the retro gaming tech space, I've seen a lot of people using AI there and it's really disappointing to me. You're right that it takes a lot of technical knowledge and deep understanding of the system, and the whole point of the endeavor is the process of getting that knowledge and becoming an expert in the system. It's a hobby, not a job; the end goal of a working emulator or whatever is just motivation to carry you along that process of learning.

So having Claude one-shot a NES emulator is almost pointless to me. You're using and looking at source code for an emulator you didn't write -- and you can learn from that, but it's not the same thing and doesn't require you to really understand a CPU the way you would by, say, observing a deviation in game behavior and staring at trace logs to figure out the exact instruction you emulated incorrectly.

It's not all bad -- AI is a great research tool and can automate some of the tedious parts (writing out an instruction decoder by hand is miserable). But using it to just...skip over the effort of doing a project defeats the whole purpose of doing those projects in the first place.

I don't want to be gatekeepy or curmudgeonly or "back in my day..." about it. But for me, my entire career path is due to skills and knowledge I learned spending several years of my life as a teenager figuring out how to write an NES emulator as a relative beginner to programming. And so I feel like using AI for this is depriving the next generation of that learning process. In addition, there are only so many retro games, and fewer popular ones. There's only so much unexplored territory to discover, and doing it with AI deprives another person of that experience and deprives that game's community of someone who might have been able to find a "home" working on projects related to that game.

> If you take "reliably" to mean "1 in 200 false positive rate" as they disclose on their front page

Pangram claims a 1 in 10,000 false positive rate (rate at which human-authored texts are incorrectly classified as AI-generated). 1 in 200 sounds like the false negative rate (rate at which AI-generated texts are classified as human-authored), or perhaps a rate for a specific category of text.

It was still crap back when it was Wikia. The website itself wasn't so bad yet, but the actual content of most Wikia wikis was very poor quality (often wrong, outdated, and/or poorly sourced; lack of maintenance and amateurish writing/presentation). I quickly learned to not click on Wikia search results whenever I could help it, whereas an independent wiki was a sign that the community cared enough to run their own servers.

The only Wikia sites that had anything worthwhile were the ones that started as independent communities and got bought out, like Memory Alpha or the Minecraft wiki.

The token should only be valid for one IP, so the scraper has to keep solving challenges if it rotates IPs.

Whoa, it's MaskRay! Your blog has been a lifesaver for me every time I've needed to understand some obscure detail about linker behavior. Thanks a ton for all your work in this area, and thanks even more for writing about it.

It's talking about two different services:

> Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com.

> iCloud+ Hide My Email addresses will remain on icloud.com.

The article is about depositing a check as an extension of credit; not spending via check. This creates a creditworthiness requirement that is in practice one of the most common reasons for someone to not have access to a bank account.

I recommend reading https://www.bitsaboutmoney.com/archive/the-business-of-check..., particularly the section "Depositing a check requires an extension of credit":

> If something goes wrong in this process—the overwhelmingly most likely one is that the payer doesn’t have the funds to cover the check (NSF, or “insufficient funds”), but the check being fraudulent or unauthorized is also possible—that wrongness may not be discovered before money “moves” to your bank. And so that payment can be recalled from your bank to the bank the check is drawn on. This will likely result in the bank attempting to recall the money from your account.

> And so by presenting your check, which you think is substantially terminating a transaction, you are actually creating a new credit extension with your bank. They are extremely aware that you just asked them to advance you money, even if you are not aware that you did that. They already partially underwrote this extension of credit; that is why you were not shooed out of the building when you originally asked for a checking account.

I had the same experience reading A Midsummer Night's Dream in high school -- I could follow the story, but it was a slog to get through and I didn't understand what was supposed to be so great about it.

Then I saw an actual performance of the play recently, and it all clicked. It was just as understandable as any contemporary film, and easily one of the most fun and entertaining stories I've seen.

> The obvious counterexample is in the foss world is ffmpeg, which I would submit is deeply understood by Fabrice Bellard

Bellard hasn't worked on FFMpeg since 2003.

I think the derailment of this thread into "is Rust's memory safety good or not" is unfortunate and tedious (this debate must have happened hundreds of times by now on this site alone), but I also think it's unfair to lay the blame on Steve for this. Steve left a thoroughly glowing comment praising Zig's work on compiler performance, and comparing to his perspective on the early days of Rust. He mentioned in passing that he's not a Zig user due to preferring to work in memory-safe languages, which was polite, brief, clearly his personal position, and in my opinion an acceptable way to disclose his relationship with Zig without derailing the thread to be about memory safety.

This comment spawned two subthreads. One of them was focused on the differences between Rust and Zig's compilation model, which is directly relevant to the article and illuminating regarding the engineering tradeoffs.

In the other subthread, pron posted paragraphs and paragraphs arguing about what memory safety really means and whether or not Steve is right to have his opinion that Rust is "safe". This tangent had essentially nothing to do with the content of Steve's comment; it (and not Steve's initial comment) was the point where the thread was derailed from the topic of Zig's incremental compilation model. Steve responded politely in this thread to comments and questions directed at him, but did not fan the flames or take the thread further into off-topicness. If the moderators collapsed pron's comment or detached it and pinned it to the bottom of the page, this comment thread would be much better and much more respectful to the Zig project.

I think the RESF trope is just about dead now; it's given way to the Rust Detractor Strike Force showing up to turn unrelated threads into tangential arguments about why Rust is bad.