Pattern types could potentially maybe in the future allow for the compiler to know more details though. They are a nightly feature, and afaik only for enums, integers and pointers so far. The idea would be that you can define a custom type such as "an integer between 7 and 45" and everything else become niches for niche optimisation (e.g. for `Option<MyFunkyInt>` some of those impossible values would be used to represent the None case of the wrapping Option).

But I could envisage a future in which you could say "f64 without NaN" which would both make those available for niches and potentially tell LLVM about this. However, we are very far from any of that currently. And it might not be what you want, since you would need to add checks when you perform operations to ensure the value doesn't suddenly become a NaN. Which is way more complicated than ensuring integers don't become, say, zero. It will likely be much harder to optimise away the checks.

Thanks, I’ll take a look!

Riven is even better. :-)

And that is just the tip of the iceberg when it comes to Gnome. I went to Xfce, MATE and then Cinnamon for some years, but I'm now back on KDE and it been good for several years (I left KDE when KDE 4 came out and went to Gnome 2).

But each to their own, use what makes you happy. But Gnome has a history of messing with your desktop, KDE less so in recent years.

1) That setting still exists, it's just less prominent.

2) Subpixel AA is no longer the default; the default is grayscale, because it works well on all screens in all orientations.

Apparently it is supposed to be on for low DPI screens. I would count mine as low DPI (even my laptop is only around 150 DPI) but I still need to set that manually.

So no, GTK didn't keep the font rendering settings I care about, and is actively hostile in trying to ignore them even.

[1]: https://wiki.archlinux.org/title/GTK#Text_in_GTK_4_applicati...

That setting is there in GNOME Tweaks; I'm looking at it right now.

(I'm not trying to dismiss the concern, here, but AFAICT the setting isn't missing.)

Also Gnome Tweaks is an add-on, not part of the default install on any Linux distro I have tried. In KDE Plasma this is in the standard settings.

And if you use any desktop environment other than GNOME, their preferences certainly won't set the GTK4 hidden ini setting. Rather they expect programs to follow best interoperability practises, such as respecting the fontconfig settings. Most people won't limit themselves to only first-party apps from their DE of choice, so interoperability is king.

Trying UBSAN and ASAN might have been worth it. I don't think comparing debug and release builds would have helped: could be buggy optimisations or UB in your code regardless of what the outcome of that test was.

1. You check in both places in code in the debugger that the address of the field matches. (Maybe the object is at the same address, but due to some build system level ifdef mismatch, you effectively get different struct definitions in different places or something like that.)

2. You add a breakpoint inside the procedure and outside it.

3. When the breakpoint inside is hit, you add a watchpoint at the address of the field. Continue. See if the watchpoint gets hit before reaching the second breakpoint.

I know that at least modern GCC and Clang will warn and/or error for this (not sure which as I use -Werror), but still, this is pointless UB to have.

And no, in this case I don't buy that a C90 compiler would have been unable to check this.

The issue is that there is a contingent of users who complains about cases where the return dynamically can't be hit but that isn't obvious statically. Consider something like this:

  int do_something(enum meow koala) {
    switch (koala) {
    case enum_val_1: return 5;
    case enum_val_2: return 3;
    /* etc., covering all the enum values */
    }
  }

If an underlying type is specified, then it should error since it is legal to have those values (unless the whole range of the underlying type is covered by the cases.

Again, that is what would be sensible from a C++ perspective, I don't know if C differs here.

EDIT: Also, and now I'm talking with my Rust user hat on: it is better to not have pointless UB. Yes some is needed to practically allow for optimisation. But C and C++ had a lot of UB that doesn't really help with making your code faster, such as this.

In C it is not UB for an enum to have an integer value that does not correspond to any listed enumeration constants.

Was it ever even theoretically under any circumstances for any reason intended to be able to write a stack of functions with no returns that just fall into each other like assembly? I can't believe it.

So it seems like something even the very first compiler could have cought right in an early parser pass or stage.

But I also decline to believe I have a better idea about something than K or R, so there must be a non-triviality I don't see. I mean goto() exists in the language so ?

... I guess simply detecting the end of a function, or detecting that the process reached the end of a function, isn't a good enough definition of the problem. You can have any number of returns or gotos in the middle that you are always supposed to hit, and intentionally no return at the end because instead you have an assert or a goto.

assert you should never get here, goto error, goto not error but just next step, etc. They might or might not be error conditions that the process reached that spot, but it's not an error that the code doesn't end with a return.

For what I work on, the hidden constant is often more important than big O. For example, a hash map has better complexity than just searching through a vector. But if the vector is small enough it will best the hash nap for actual time. Just plain searching until you find the element will even beat binary search on a sorted vector for small enough vectors. The reasons are complex, to do with cache, prefetch, branch prediction and also just how many instructions your tight inner loop has. (And the specific reasons will vary between desktop class CPUs and microcontrollers. But both exhibit this pattern.)

You could argue that at that point why bother optimising at all (there aren't a lot of elements in the collection after all). But there are two distinct cases I have come across over the years where it still matters (and for what I work with, they represent the common cases):

* You need to look up in a small collection a lot (either lots of lookups into a few small collections or a few lookups each into lots of different small collections, I have seen both cases).

* Hard realtime code where predictable latency matters. Hashmap has a bad worst case, binary trees and binary searching has badly predictable memory access patterns. And in this case the collections are usually small anyway (there are only so many actuators and sensors your equipment has, and/or the embedded microcontroller doesn't have a lot of memory anyway).

This will all depend on the size and type of object stored in a vector.

If you have a relatively small and flat struct that you are storing, then sure that will likely win. But if you are working with a collection of pointers, then the hash map will (almost) always win.

> Hard realtime code where predictable latency matters. Hashmap has a bad worst case

The hash map worst case is a linear search. It will be a lookup + the search. This also depends on the implementation. You could, for example, use a robinhood hash map which trades insertion times for lookup times.

A bad hashmap implementation will store collisions in linked lists. A better one will try and put them in a b-tree. An even better one will use a vector for collisions. And the most cache friendly version stores everything in the table and does probing on collisions.

There are specific cases where vectors are better, but those are the exception and not the rule in my experience.

Also, while on a desktop class CPU any pointer chasing you do tends to dominate, that is not the case on small and medium microcontrollers (which I work with a lot). They have very short pipelines and their memory is all internal SRAM most of the time. Here classic cycle counting is still king, so you need to ask yourself if it is quicker to compare the key than to calculate the hash and compare hashes.

Code size in general matters a lot on embedded. Even a simple hashmap will always have more code than a simple vector. And a state of the art implementation with probing and tombstones (such as swisstable in C++ and hashbrown in Rust) will be way too large to be usable.

But if I'm making a presentation for a conference I would choose differently. And in between you get a whole spectrum of tradeoffs.

While this works for encryption, it doesn't really work for explaining signatures or however. Maybe someone can come up with a good analogy for that case.