Could be that the new 100% and 0% are something like the old 80% and 20%

"nightly" versions also allow to use unstable features, and unstable features may remain so for a very long time (potentially forever) without breaking, so an old nightly could maybe work

Right, not everything gets merged to stable. In that case: letting us know the specifics beyond "nightly" is advisable, IMO.

The readme does mention the specifics, immediately after mentioning nightly.

> BREAKPOINTS REQUIRE ENABLING THE EXPERIMENTAL core_intrinsics FEATURE

How do I know which versions of nightly support that feature, and that specific version of the feature though?

I like your username.

Just use a recent nightly and you should be fine. Rust project doesn't offically provide support even for old stable versions, so "using nightly" with no specifics generally means using any nightly build, around or newer than, the current stable release.

I read parts of the Linux kernel source code pretty often, and getting the definition of a function is often pretty involved:

- I don't always know the return code type, as the calling code assigned a field whose definition I don't know to find either

- I don't know if it's a C function or a preprocessor macro

This often results in me searching for the exact function name, and combing through the uses in the drivers. You then need to re-start all that recursively to understand the function you just read.

I could use clangd for that, but I don't have the ressources on my laptop to compile a kernel

You might find this site useful: https://elixir.bootlin.com

Why not simply hold Ctrl and click on the name of the function?

> I don't have the resources on my laptop to compile a kernel

ctags?

I have not really thought too far ahead, I know quite a bit about Linux internals, so when in doubt I tend to follow what was done there. I have not though very far in how to handle most of syscalls, traps, drivers, ...

Thank you for the static site generator! The code highlighting should be very similar to the tokyonight nvim colorscheme, as it uses mostly the same colors & tree-sitter queries as it!

Well yes, but I the main idea of this series is to use no dependencies in order to have a deeper under standing of the entire stack, from boot to GUIs (that is a long term goal!)

Well this part did not have much RISC-V in it, as it builds upon the abstractions of part 2, which had lots of assembly!

I think they meant if you cast a pointer to an integer, do some math on that and then store that. Then you will a stored result that will likely differ from run to run

That sounds like runtime differences not a difference between two binaries

The difference in binaries must be caused by some runtime difference of a compiler.

That's right, look at this thread for example:

https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20...

The Global Value Numbering pass in LLVM was iterating over `DenseMap<BasicBlock*, ...>`, so the iteration order was dependent on the value of BasicBlock pointers. This could lead to the same source files and compiler producing different binaries.

I think in High-Performance Computing a lot of the networking NICs behave in that way, because you are 100% sure that you know the fabric layout.

Stuff like InfiniBand, HPE Slingshot, Atos BXI, ... There is a consortium that's building a specification for those kinds of things: https://ultraethernet.org/

I got bitten many times by the fact that PATH is not taken into account, because I use Nix to manage by dotfiles, including `clangd`, but when developing libraries that target the base distro (not Nix) clangd sometimes gets confused and does not taken into account the headers in /usr/include, only the Nix headers....

I had a situation where I'm not really sure I could have used something else than null: I need a value in one of two columns exactly (meaning one is NULL and the other not).

You can build a constraint to check that if it's in the same table, but across tables it seems to be a bit more complex right ?

You could have the first column indicate the type of value and the second column the value. If you now have your columns named "a" and "b" you could have the first column named "type" only allowing values "a" or "b" and the second column would be "value" where the actual value is stored.