fonheponho

> In an era of extremely accessible and competent language models, you have no excuse not to use one to verify your doctor's (or any hired professional's) work [...] the tools exist and are now ridiculously accessible

Well I certainly have an excuse: at work, code reviews provided by a particular LLM have been a net negative contribution, in my judgement. And then it's not hard to extrapolate that experience to other professions, ones that I myself am not competent in.

The old adage exists where you read the Sunday newspaper, get a nice educative experience from 14 out of the 16 pages, but then 2 pages happen to write about your own profession, and you seethe about the rampant stupidities and mischaracterizations in those 2 pages. But the other 14, about stuff you are not directly familar with, sound good. See the problem?

You got lucky because your doctor was receptive to ideas from sources other than his own brain (LLM or otherwise). Most medical professionals laugh you (or curse you) out of the room, if you attempt to make an informed decision. In fact the most selective search criterion for doctors, as a patient, is willing to talk.

> The other knock on lesson that people should internalize is that you, and only you, are ultimately responsible for your own healthcare and maintenance.

Yes and no.

Yes in the sense that it's ultimately you who will get fucked up; you'll be the victim, you're the one punished for the mistakes of others.

And no in the sense that the social contract says different -- otherwise, you'd be responsible for baking your own bread AND manufacturing and fixing your car AND writing your own computer & smartphone programs AND taking care of your health AND educating your children AND cultivating your land and growing your own produce AND so on and on. We have "distribution of work" for a reason; you take the money, you take responsibility. (Except most doctors.)

So, "no", it's not your job, but "yes", you're held accountable for it.

Just because the social contract gets violated left and right, the violations aren't right.

People always emphasize that responsibility and authority should go hand in hand, and this is a prime example where that principle is shown invalid -- it's a human construction and does not hold up in nature. You have no authority to even understand your own health sufficiently, yet you get to bear the consequences.

What you are arguing for is that everyone should judge a professional from a position of lacking education / information. That's precisely what the social contract is not. I'm not saying you are wrong, I'm saying the state of the world is fundamentally wrong; it's way too easy to disclaim responsibility. Someone takes my money, they're on the hook.

People shouldn't trust the social contract, but you can't blame them for trusting it. Most of the time there's no way around trusting it.

> This is all professionals. [...] Just take any profession that your retail consumer might get access to and the same spread applies.

The big difference is that if those other professionals fuck up, then the damage is usually done to some object. An object you can get fixed again (by someone else), or replaced, or you can even throw it away perhaps. This doesn't apply to doctors. The damage they can do can be irreversible, the damage is done to your body. This means they should take all the more responsibility. Yet what we see is that they disclaim responsibility to such a huge extent that most of those other professionals can't.

Most doctors have a god complex.

(Whether Hungarian qualifies as Finno-Ugric is up for debate, but Hungarian most definitely has determinate and indeterminate articles.)

My guess: Czech. :)

Native English speakers living for a decade or more in the Czech Republic (and picking up Czech in the process) may experience "retroactive article confusion", they may start to drop articles while speaking their mother tongue English.

I have no love lost for Wayland, but this:

> Make easy things easy. Make hard things doable.

is generally unachievable. Instead, pick one:

- easy things easy, hard things impossible

- easy things tedious, hard things possible

(Unless you want to maintain two sets of interfaces in parallel.)

Everybody seems to be missing the forest for the trees on this.

There is absolutely no "sign extension" in the C standard (go ahead, search it). "Sign extension" is a feature of some assembly instructions on some architectures, but C has nothing to do with it.

Citing integer promotion from the standard is justified, but it's just one part (perhaps even the smaller part) of the picture. The crucial bit is not quoted in the article: the specification of "Bitwise shift operators". Namely

> The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. [...]

> The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1×2^E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1×2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.

What happens here is that "base2" (of type uint8_t, which is "unsigned char" in this environment) gets promoted to "int", and then left-shifted by 24 bits. You get undefined behavior because, while "base2" (after promotion) has a signed type ("int") and nonnegative value, E1×2^E2 (i.e., base2 × 2^24) is NOT representable in the result type ("int").

What happens during the conversion to "uint64_t" afterwards is irrelevant; even the particulars of the sign bit of "int", and how you end up with a negative "int" from the shift, are irrelevant; you got your UB right inside the invalid left-shift. How said UB happens to materialize on this particular C implementation may perhaps be explained in terms of sign extension of the underlying ISA -- but do that separately; be absolutely clear about what is what.

The article fails to mention the root cause (violating the rules for the bitwise left-shift operator) and fails to name the key consequence (undefined behavior); instead, it leads with not-a-thing ("sign-extension bug in C"). I'm displeased.

BTW this bug (invalid left shift of a signed integer) is common, sadly.

One of the most fascinating and moving writings I've read in my life.

Exactly; I can't understand this obsession with header-only C "libraries".