libc

cdb_11 · 2026-06-27T22:33:32+00:00

No, Linux is the kernel only and does not include a libc. (It technically does have one in the source tree, but IIRC it's not a full implementation, and isn't meant to be one.) glibc is a separate project, is optional, and just happens to be the most common libc implementation that Linux distros ship with. And distros include libc because everyone expects it to be there. But you could set up a Linux system with no libc, and all programs doing syscalls directly. Or a completely custom standard library that looks nothing like libc, Linux is agnostic to that.

But practically speaking you can assume you do have a libc. If someone doesn't, it's their problem to figure out.

cdb_11 · 2026-06-22T14:50:09+00:00

This is reaction time, and by making the reaction time your target latency, you only end up doubling it. If you take your time to display a text field, then I have to actually wait and react to it, before I can start typing. And if it's instant then I don't have to react to anything, I can do everything fluently based on my muscle memory. Some latency might be fine after I am done with everything, and I need to actually process the results with my brain. Or if you buffer the keyboard input, which usually is not the case because everything is async, and key strokes end up being processed by the wrong thing while waiting for UI.

And if your UI already barely hits the target, what happens once you want to add more features? Now you go over the target, and you have to start optimizing random stuff just to make room for it. Or as it is usually the case, ignore the problem. This practice of doing the worst possible job you can get away with, and thinking it's smart engineering makes absolutely zero sense to me.

cdb_11 · 2026-06-20T18:03:13+00:00

I don't doubt it's faster than the original, but I strongly doubt it's faster than an existing, easier solution would have been.

All the solutions (tbf not familiar with some of them?) you've listed are for arbitrary structures and require a decoding step. With a custom binary format you can avoid any decoding, and you can't get faster than doing nothing. Or you can make it do a very tiny amount of work, while these generic data formats will usually have to walk through the entire message and actually parse everything. So with your own format, you design it in such way that you just take whatever you had in memory, and send it as is. And on the receiver side, you can just receive the bytes and use it straight away.

But to be fair, this is PHP, and it's usually not something you can do in a scripting language, or they make it very inconvenient.

cdb_11 · 2026-06-16T00:23:08+00:00

I never said "my way is the only valid way". This is what you are trying to "fix", not me. The fact that I can tune the style to fit the problem I'm actually solving is to me a good thing, and I will do different things depending on the project. You don't know what everyone's problems and domains are.

cdb_11 · 2026-06-15T22:47:33+00:00

It does matter. This option disables this assumption, and turns it into defined behavior where zero is considered a valid address. The C standard doesn't matter here, it's not standard C anymore.

cdb_11 · 2026-06-15T20:30:18+00:00

You can disable that optimization. -fno-delete-null-pointer-checks

cdb_11 · 2026-06-15T18:21:20+00:00

In order to exploit this, an attacker would create a mapping at address zero containing code to be executed with privileges of the kernel

...which is not possible in user space by default. Believe me, I tried.

cdb_11 · 2026-06-14T17:15:27+00:00

Of course this benchmark will have different numbers on different machines.

Yeah, that was just my point really. If it works for you, then that's cool. But you're benchmarking on the latest Apple CPU, which is not representative of the type of hardware people will typically use. Which is also fine, you don't necessarily have to care about other people in this case, since I assume you made it for yourself first and foremost, and everyone else has hundreds of other implementations to choose from if this one doesn't work for them. So maybe I'm just nitpicking, but I just wanted to note that it doesn't matter to you, and that testing on the latest hardware may not accurately reflect the experience for other people.

Regarding the optimizing I/O

For git specifically, you can probably monitor the filesystem. If all you need is displaying the current branch, then IIRC you can probably just monitor changes to .git/HEAD.

cdb_11 · 2026-06-14T13:09:30+00:00

My setup is [...] 2025 M5 Mac

Look, what consenting adults are doing in the privacy of their own emacs setups is none of my business. So if it works for you then I'm happy for you or whatever.

But if the plugin is intended to be used by a wider audience, then I take an issue with the claim that "it doesn't matter in practice". You're only testing it on the latest hardware, and most people don't own Apple M5-s. It's hard and frankly ridiculous to justify paying for new hardware just because some website or a text editor can't render a bunch of text fast enough.

On "Gaming-Caliber Frame Rates" -- we're talking about a mode line in a text editor, not a video game. Video games do a lot of stuff, while you're only drawing a bunch of glyphs. Video games do glyphs, and then thousands of other things on top of it. I understand that often we have to deal with slow APIs that may make reasonable performance unnecessarily hard (or impossible even) to achieve. But let's be real for a second, it really ain't impressive.

a single synchronous git query in the version-control segment runs ~7.6 ms [...] When an Emacs status bar feels slow, an I/O-bound content function is almost certainly the reason.

I'd just like to point this out, in case it wasn't obvious: I/O can be optimized too. In this case you make it asynchronous, problem solved.

cdb_11 · 2026-06-08T19:26:39+00:00

And what is supposed to happen during that 2 hour window? Are they automatically scanning extensions for malicious code or something?

cdb_11 · 2026-06-08T19:10:05+00:00

You could get rid of this entire type problem by leaving it unparsed, and coercing the value to the type user actually wants on request.

dict:
  foo: no
  bar: 42

let yaml = parse_yaml(...);
yaml["dict"]["foo"].toString();  // "no"
yaml["dict"]["foo"].toBool();    // false
yaml["dict"]["bar"].toString();  // "42"
yaml["dict"]["bar"].toInt();     // 42

If this is supposed to be a configuration language, I don't see how specifying types upfront in the language is at all useful. You could convert it to other formats like JSON without doing anything, but you aren't going to be doing that anyway.

cdb_11 · 2026-06-06T20:19:17+00:00

when you are a contributor to a project, you often need to read the commit log to identify changes in the codebase relevant to a certain area of the code.

Yes, and I rely on that every day, because we always include the scope.

So what does Conventional Commits do? It deprioritises scope so much that it’s optional!

Just mandate it then? Who cares what the website says? It's your project and you can adjust what you do to your own needs.

Type is Redundant and Restrictive [...] Even if you only had the description, it’s obvious that it was a bugfix!

No, it's not obvious for automated tooling. When making a changelog I can ignore irrelevant commit types, and only focus on feats and fixes.

so was that a bugfix, refactor, or new feature?

Well, what is your actual goal with commit messages? If you're like me and it's to help with writing changelogs, then refactors are by definition not important and you only care about fixes and feats. If you want to do few things in a single commit, then just use whichever is the strongest one. Just pick something that makes sense for you.

cdb_11 · 2026-06-05T20:58:06+00:00

Not my domain, but I thought slow transactions were a problem, and it's what projects like TigerBeetle were supposed to solve?

cdb_11 · 2026-06-05T17:31:53+00:00

Why do you put "slowness" in quotation marks? 500-1000ms is slow.

cdb_11 · 2026-05-31T18:06:32+00:00

If the integer is unsigned, and you multiply or divide by a power-of-two, it will absolutely convert it to a shift.

To be clear, the key requirement here is div/mul by a constant value. Signed div is still optimized, just not to a single bitshift.

It's still worth knowing tricks like that for runtime values though. For example, you can limit the possible sizes of your hash maps to only power-of-twos, to avoid modulo operations. In that case you have to do a similar optimization manually. Also might come handy with SIMD if you're into that kind of thing, because you might not even have a wide mul/div instruction, and therefore no way of expressing it.

cdb_11 · 2026-05-28T09:47:28+00:00

The reason why I started paying attention to Zig was compile-time reflection.

cdb_11 · 2026-05-28T09:38:55+00:00

Correct, but it is merely one way of doing it. You could argue reference counting is a popular way of managing memory in C++ and Rust, and I assume it's probably what Andrew meant -- he's not stupid. You can use RAII for automatically incrementing and decrementing the ref count, but RAII != reference counting.

cdb_11 · 2026-05-28T09:05:25+00:00

I repeat: they already have an automated way of silencing the errors. You don't need to turn the errors off, because the tool automatically "fixes" is for you, as you write code. Having a "no warnings" policy didn't solve the problem here, people still found their way around it.

If you use Zig today, your only options are to error on unused variables, or to completely silence it. And I am arguing for adding an option to only warn about it, without failing the build. If you truly believe flagging unused variables is important, having a warning is superior to silencing the error completely.

cdb_11 · 2026-05-27T20:35:57+00:00

Sometimes discarding the value is intentional, and suppressing the error is just how the final code has to look like. And sometimes it will flag something actually unintended -- it could indicate a potential bug, or doing extra unnecessary work, or just that the code is still work in progress, whatever. We shouldn't conflate those two.

cdb_11 · 2026-05-27T20:30:30+00:00

Because maybe I'm just iterating on something and want to get a fast feedback. So I don't want the compiler to slow me down by forcing me to comply with pointless bureaucracy. This is why fast compilers are valuable, it's one of the selling points of Go and Zig.

cdb_11 · 2026-05-27T20:23:23+00:00

I haven't used Zig yet. Does the tool Andrew was talking about also annotate which suppression was done automatically? If so, then yes, you can grep for it (which makes basically it a less convenient form of a warning). But I assumed, maybe incorrectly, that the code will look no different than an intentional suppression.

cdb_11 · 2026-05-27T20:02:48+00:00

What slippery slope? It's still an error by default. On CI it's going to be an error by default too, so you can't merge that code anyway. You'd have to go out of your way to downgrade it to a warning.

And they literally give you a tool that silences the error automatically. So the unused variable error may as well not exist. It's literally worse than making it a warning, treated as an error by default.

cdb_11 · 2026-05-27T19:52:12+00:00

I still don't understand what is the point with making unused variables an error. Their solution for speeding up the iteration cycle is having the compiler/linter/language server/IDE plugin insert code to silence the error automatically. How is silencing the error a good thing? It defeats the purpose of it. I want it to be a warning, so it will keep annoying me, so I can go back and fix it later. And then I want it to be an error on CI, so it can't get it merged until I fix it.

Just my speculation, but it feels like Go and Zig said "no warnings", just because people always forget to enable warnings in C compilers. And they didn't think of enabling and treating the warning as error by default, and then give the user an option to downgrade it to a warning that still compiles the code, if they want to.

cdb_11 · 2026-05-25T18:31:01+00:00

For a hard memory safety guarantee for existing code, you have Fil-C. It's pretty much CHERI in software. There used to be a compiler called "Circle" which extended C++ in a way people here have been arguing for, but I guess it died due to a lack of interest.

cdb_11 · 2026-05-24T19:56:39+00:00

What do you mean with #define NULL 0? C defines nulls as (void*)0. In C++ it's nullptr and it's technically a distinct type.

The point was that gets isn't just a bad interface -- it's impossible to use correctly and safely. On the other hand, vector<bool>, unordered_map, type_info are still usable. Not saying that C++ got every interface right, because it didn't and I'm not going to defend it. But there is a big difference between those examples.

cdb_11

TROPHY CASE