munch117

Compare with this:

  double f(void* p) {
    return * (double*) p;
  }

No one is surprised that defensive code isn't issued to guard against p being NULL, unaligned, or pointing to a uint16_t. You told the compiler that p is actually pointing to a double, and it generates code accordingly.

It's the same thing here: You told the compiler very explicitly that anything following this point is unreachable, and it generated code accordingly.

I'm not defending writing code with UB. I would have preferred the compiler issuing a warning saying "you say this is unreachable, I don't believe that it is", when it's this obvious. Maybe issue a trap instruction. But there's nothing wrong it, per se. When you choose to override the compiler's judgment and insist that this point in code is unreachable, then the compiler takes your word for it.

Of course things go badly once we reach "unreachable()", continuing into the next function because the compiler didn't bother to add a "ret". That's no surprise, "unreachable()" is basically an instruction to the compiler to stop generating code from that point on, and the compiler obeyed.

Before that the observable side-effect, device_command=42, has already happened. With time travel allowed, could also have been omitted, which would have been a real problem.

I misread the article to think that is was about the latter problem. You are right, my mistake. I didn't consider that anyone could see the former as a problem at all: It's just the compiler doing exactly what it's told to do.

C23 also has the "no time travel" stipulation. I expect C23 should be immune to the example 1 program issue, because of that. A quick trial on godbolt (https://godbolt.org/z/8K81PYoYE) seems to agree, with the caveat that I didn't work out the right compiler options to show for sure.

The default for paragraph layout does suck indeed. But at least the font you should be able to customize.

The page does not set a text size. You are complaining about your own browser's defaults.

Skeuomorphism didn't fail. It feel out of fashion with designers.

We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.

But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.

I read the or's as giving alternatives, only one of which needs to work.

I can see how other interpretations are possible, but I don't see anything especially generous about mine. I'm not "allowing" anything: To make a judgement you have to pick a web browser to try it with, and you'd probably pick the most popular one, in the most popular configuration, that seems the most fair. If that web browser happens to execute Javascript when you navigate to an URL, then that's just how it is.

If the text was returned using a staged process, whereby the server first returns an instruction (JavaScript), and the web browser then executes that instruction, which is what transfers the text, then that doesn't actually change anything. Those are just technical details of the transfer. You are viewing an HTML document on-screen; it makes no difference to this bet if it was returned to you by a different mechanism than originally conceived, since the bet doesn't specify any transfer mechanism, just that the URL was entered into a browser.

I think you are absolutely right.

The big problem with the Turing test always was that it doesn't take into account adversarial designs. They had those chatbot contests about a decade ago, where the chatbots would regularly pass the turing test, not because the bots were intelligent, but because they were packed with rhetorical tricks designed to avoid saying anything of substance.

By any meaningful measure, today's LLM's pass the Turing test. Except we may need to lobotomize them for the deception to work.

Absolutely store the raw data. For the reasons you state.

But also store derived data. Titles, authors, dates, article texts. You need those for whatever your application does. You don't want your application logic to be working with the raw text.

> how will you handle updates to the feed?

When polling, consider using HTTP HEAD to check for changes before GET.

What you do when an article ID reappears with different content, that up to you. I think readers usually replace the old entry with the new content, silently. But it's not the only option.

Perhaps you are talking about the ripgrep issue itself, which is fine. The others are talking about the linked analysis, which is not.

I would say that's a very sugarcoated version of the Monster energy drink ingredients list[1]. The real list is ten time longer than the ingredients list of a cup of black filter coffee. And one of the items is "natural flavors", which could be hiding a long list of things all by itself.

[1] https://nutritionandingredients.com/monster-energy-drinks-in...

For a piece of software designed by reading the specs and implementing accordingly, there acid3 would be a good way of demonstrating the quality of the result.

But is that what happened? If you pass tests that conflict with the specs, then that implies that the implementation is not based on specs, but on feedback from the test. Which means it may be designed to pass the test, and not much good once you go outside the test examples.

I'll extend the benefit of the doubt and say that it's possible that the implementation is based on an older version of specs, one that matches the tests. But it doesn't inspire confidence that all we're shown is a single screenshot and no source code.

Invisible until moused over, or scrolled by other means. Barely visible even then. In the wrong place. It may be "just styled", but it's certainly not fine.

If ease of repair is what you care about, then yes.

But in absolute terms, sockets do make things more likely to fail. A socketed design means you have an assembly step where something is put into that socket. Probably manually. Cables and sockets can be tugged at and twisted. Dirt and moisture can get in between. Suppliers can use the wrong metal in connectors. Some errors will be caught by QC, which means that you never see them, but they still affect the manufacturer's bottom line.

Like bot403 said: "Just depends on what your priorities are."

Connectors are points of failure. The less of them, the more reliable.

The fatal flaw in PG's argument is that is doesn't mention spending at all.

If you're spending your entire income on things like food and rent, then a 1% wealth tax corresponds to 0% income tax.

If you're spending your entire income on investment, then there's a calculation like PG's to be made to compute an equivalent income tax rate. But then we're talking about someone who doesn't need the money. This isn't even about rich vs. poor - you can have a high income and spend it all as you make it, like if you throw a huge party every week, or make a yearly trip into space. But if not, then it's just an ever growing number on your bank statement, and the only reason you care about it being 20% higher is because you're comparing it to other people's bank statements.

I didn't suggest that implementations should entirely eliminate every form of UB. There is plenty of middle ground. For example, you could easily limit the consequences of integer overflow by specifying or partially specifying overflow behaviour, with very little runtime cost.

I'm not suggesting you change how you write code, but with a better implementation the code that you do write - that lives in the real world where mistakes are made - might work better. How is that being pedantic?

An interesting case where compiler writers did something like that is casting via union members, but I'm running out of time, so we can talk about that another day.

Both are wrong. It means "this standard does not constrain the behaviour of code that does this".

It's entirely legal for implementations to have predictable behaviour, documented or not, for code that is undefined by the standard. In their quest for maxxing benchmark performance they generally choose not to, but there's really nothing in any standard that stops you from making an implementation that prioritises safety.

Making a plan that works for the general case, but is also efficient, is rather trivial. Here's pseudocode from spending two minutes on the problem:

    # INPUT: lookfor: unicode
    var lower, upper: ascii
    lower = ascii_lower_bound(lookfor)
    upper = ascii_upper_bound(lookfor)
    for candidate:ascii in index_lookup(lower .. upper):
        if expensive_correct_compare_equal(candidate.field, lookfor):
            yield candidate

The magic is to have functions ascii_lower_bound and ascii_upper_bound, that compute an ASCII string such that all ASCII strings that compare smaller (greater) cannot be equal to the input. Those functions are not hard to write. Although you might have to implement versions for each supported locale-dependent text comparison algorithm, but still, not a big deal.

Worst case, 'lower' and 'upper' span the whole table - could happen if you have some really gnarly string comparison rules to deal with. But then you're no worse off than before. And most of the time you'll have lower==upper and excellent performance.

> Just clearly state your requirements.

Nothing new here. Getting users to clearly state their requirements has always been like pulling teeth. Incomplete sentences and all.

If the people you are teaching are developers, they should know better. But I'm not all that surprised if many of them don't. People will be people.

TNG, by a country mile. B5 has "writer identifies too much with the main character" written all over it. It's the story of how Our Great Leader does the right thing and saves the world, over and over again.

I was reading https://www.offsec.com/blog/cve-2026-24061/, which implies that precisely that single long string passes through getenv("USER") in the attack. The mystery is how that single long string in telnetd becomes two separate arguments for login. execv or posix_spawn certainly won't do that. So either there's a version of /usr/bin/login that parses arguments in some very sus way, or there's a shell involved somehow.

I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along.

What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:

  $ login '-f root'
  login: illegal option --  

What's telnetd doing differently? Is it invoking login via a shell?

> Also worth noting that the author never actually stated that they did not use generative AI for this article.

I expect that they did in some small way, especially considering the source.

But not to an extent where it was anywhere near as relevant as the actual points being made. "Please don't complain about tangential annoyances,", the guidelines say.

I don't mind at all that it's pointed out when an article is nothing more than AI ponderings. Sure, call out AI fluff, and in particular, call out an article that might contain incorrect confabulated information. This just wasn't that.

I struggled a bit with what to point to as signs that it's not an LLM conception. Someone else had commented on the headlines as something that was AI-like, and since I could easily imagine a writing process that would lead to headlines like that, that's what I chose. A little too confidently perhaps, sorry.

But actually, I think I shouldn't have needed to identify any signs. It's the people claiming something's the work of an LLM based on little more than gut feelings, that should be asked to provide more substance. The length of sentences? Number of bullet points? That's really thin.

This article is just about as un-AI written as anything I've ever read. The headings are clearly just the outline that he started with. An outline with a clear concept for the story that he's trying to tell.

I'm beginning to wonder how many of the "This was written by AI!" comments are AI-generated.

A __del__ that does any kind of real work is asking for trouble. Use it to print a diagnostic reminding you to call .close() or .join() or use a with statement, and nothing else. For example:

    def close(self):
        self._closed = True
        self.do_interesting_finalisation_stuff()
    def __del__(self):
        if not self._closed:
            print("Programming error! Forgot to .close()", self)

If you do anything the slightest bit more interesting than that in your __del__, then you are likely to regret it.

Every time I've written a __del__ that did more, it has been trouble and I've ended up whittling it down to a simple diagnostic. With one notable exception: A __del__ that put a termination notification into a queue.Queue which a different thread was listening to. That one worked great: If the other thread was still alive and listening, then it would get the message. If not, then the message would just get garbage-collected with the Queue, but message would be redundant anyway, so that would be fine.

> If you think you disagree with him (as I once did), please consider the possibility that you've only been exposed to an ersatz characterization of his argument.

My first exposure was a video of Searle himself explaining the Chinese room argument.

It came across as a claim that a whole can never be more than its parts. It made as much sense as claiming that a car cannot possibly drive, as it consists of parts that separately cannot drive.

Ah, I missed that 9.a-c were alternatives. And that, in the absence of custom tables or functions, they are merely defense in depth for something that is already secure, barring bugs. I withdraw my concern.