badmintonbaseba

Fake title drops is one of my favorite memes, which is a screenshot from a movie/series with fake subtitles. Example:

https://preview.redd.it/in-the-netflix-original-series-resid...

edit: oops, just noticed the article also mentions the meme

Intelligence is not inherently quantifiable. IQ is an arbitrary way to quantify it, but there average and median is pretty much equal by definition.

> This effectively means you need to use RAII guard objects like in C++ in async code if you want to guarantee cleanup of external resources. But it's otherwise completely well behaved with epoll-based systems.

Which limits cleanup after cancellation to be synchronous, doesn't it? I often use asynchronous cleanup logic in Python (which is the whole premise of `async with`).

I don't think that cancellation is inherently problematic, but it needs to be cooperative. One-sided cancellation of threads (and probably goroutines) can never work.

Cooperative cancellation can be implemented in languages that mark their suspension points explicitly in their coroutines, like Rust, Python and C++.

I think Python's asyncio models cancellation fairly well with asyncio.CancelledError being raised from the suspension points, although you need to have some discipline to use async context managers or try/finally, and to wait for cancelled tasks at appropriate places. But you can write your coroutines with the expectation that they eventually make forward progress or exit normally (via return or exception).

It looks like Rust's cancellation model is far more blunt, if you are just allowed to drop the coroutine.

> He recommends testing for non-server use cases, desktops for example. ""I believe it is as stable as any other rolling release"" due to all of the checks and procedures that the distribution has put in place.

AFAIK testing is worse than both unstable and stable regarding timely security fixes. In unstable you get a timely fix from upstream, in stable you get a fix by the security team.

> Within a few years of working on compilers I came across my first examples of 50k+ line functions. These were often (but not always) the result of source code generators that were translating some kind of problem description to code.

Like the issue in the Linux kernel recently where they had some simple looking min/max macros that generated megabytes of source code.

Adopting what static analyzers do is a no-go, as they rely on non-local reasoning, even across translation units for lifetime and aliasing analysis. Their output highly depend on what they can see, and they generally can't see the source code for the whole program. I also doubt that they promise any kind of stability in their output across versions.

This is a not a jab against static analyzers, by all means use them, but I don't think they are a good fit as part of the language.

I never saw a compiler generating these instructions on its own. Compilers do produce popcnt and bswap from recognized algorithms, so I guess it's not entirely unreasonable, but I think the benefit would be marginal.

Tracking allocations is necessary, but not sufficient.

  struct S {
    int arr1[100];
    std::string s;
    int arr2[100];
  };

  void foo(S& s) {
    //arr1 and arr2 are in the same complete object
    //so they are in the same allocation
    std::sort(std::begin(arr1), std::end(arr2));
  }

To make it sound you really need to track arrays specifically (including implicit single-element ones), not just allocations.

It's surely somewhat feasible, as the constexpr interpreters in compilers do track it, but something like that would probably be way inefficient at runtime.

Nice bit twiddling hack! There are also the PDEP and PEXT instructions on x86 that could be used for this purpose, but it's possibly not worth it here.

"The optimize attribute should be used for debugging purposes only. It is not suitable in production code."

https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Functio...

Maybe this is overly naive, but I always wondered whether timing side channels could be mitigated by scheduling authentication responses before doing the crypto calculations.

1. authentication request arrives

2. schedule response at a later time, generously leaving time for doing the next step

3. do part of the work that is sensitive to timing attacks

4. respond at scheduled time

I get that assembly gets you closer, but does it actually give you the guarantees that you need? Do you have detailed documentation of what instructions and patterns you can use to avoid timing and other side channels that applies to many CPUs that implement an instruction set?

By cutting off do you mean that it correctly rounds towards zero? Maybe you can implement rounding to closest by just doing the calculation in a one digit wider mantissa with rounding to zero and observing the last digit, at least for an even base. It won't be rounding to even though, but for that a 2 digit wider mantissa is probably enough.

Rounding to nearest with an odd base doesn't seem to be as straightforwardly implementable from rounding to zero calculations at a higher precision.

The cppreference page says:

> If the program adds specializations for std::is_fundamental or std::is_fundamental_v, the behavior is undefined.

This is an oversimplification. The actual rule is https://eel.is/c++draft/library#namespace.std-2 .

> the specialization meets the standard library requirements for the original template.

For is_fundamental<YourClassType> it means that is_fundamental<YourClassType>::value must be false, as YourClassType is not a fundamental type, as defined in https://eel.is/c++draft/basic.fundamental#17 .

Some traits are just not designed to be customization points.

Possibly could be combined with C23's _BitInt(N) for the template arguments? I think it's available in clang as a C++ extension.

edit: or I guess you could have your own Tmantissa and Texponent types as custom classes that correctly model _BitInt(N), they don't seem to be required to be builtin integral types.

Nice!

> TODO: (configurable) rounding support

What's the default rounding mode? Round to nearest even?

You might be interested in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33... too, which is a recent paper for introducing reproducible floating point to C++.

Very small floating point types can be handy for exhaustive testing of floating point function templates, especially ones that take multiple arguments. Walking over all floating point values for a small type often finds most if not all corner cases that can manifest with a floating point type of any size.

I wouldn't count the coverage of integration tests with the same weight as coverage from unit tests.

Unit tests often cover the same line multiple times meaningfully, as it's much easier to exhaust corner case inputs of a single unit in isolation than in an integration test.

Think about a line that does a regex match. You can get 100% line coverage on that line with a single happy path test, or 100% branch coverage with two tests. You probably want to test a regex with a few more cases than that. It can be straightforward from a unit test, but near impossible from an integration test.

Also integration tests inherently exercise a lot of code, then only assert on a few high level results. This also inflates coverage compared to unit tests.

There are multiple problems with that:

1. The code uses internal interfaces, not meant to be used by users of the code.

2. The code might not use the high level public interfaces you are interested in. Those interfaces are meant to be used by users, and tested by tests.

Having said that reading the code itself is often fruitful. Not for example usages, but to just learn how the thing is implemented.

Yes, it's very much undefined behavior. As I recall, GTK's glib does this all over the place for signals.

edit: I'm not advocating that this being UB is fine. I don't expect compilers to exploit this for optimization, because so many projects rely on this working. There might be room to extend compatible function types to make this defined.

Valgrind is great, especially if you write extensive tests and you actually run them through it regularly. And even then, it does not prove the absence of any kind of bugs. Safe rust has strong guarantees.

AFAIK the state of the art now is "dragonbox":

https://github.com/jk-jeon/dragonbox

Nit: "unspecified behavior" isn't a thing, at least without some further qualifications. It's usually "unspecified result", or "unspecified result or trap" for certain operations. "unspecified behavior" without further qualifications is just "undefined behavior".

Having said that, an "unspecified result" can still come from anywhere, like a value left in a register from some previous computation or other "garbage" on the stack or heap. This still can be a security issue, even though the behavior is not completely undefined.

Is it possible for that setup to show up as a virtual display on your main WM/DE, so you just extend to it, or does it need to run its own, separate instance? Can you drag a window from your main DE to the virtual display?

Unless you happen to be presenting on how reference counting can leak with circular references.

This is behavior is mostly just unspecified, at least for C++ (not sure about C).

I'm aware of some efforts to bring deterministic floating point operations into the C++ standard, but AFAIK there are no publicly available papers yet.

If my calculations are correct, then for this variation the enclosed n-sphere's radius converges to sqrt(2)-1 from below, and remains enclosed in the bounding hyper-tetrahedron.

How does the enclosed sphere's radius changes with the number of dimensions, if the enclosing spheres are the following:

2D: 3 mutually touching 2-spheres (circles)

3D: 4 mutually touching 3-spheres (or spheres)

...

This variation of the problem doesn't rely on an artificial construct of a hypercube, I wonder if this yields a similarly unintuitive result.

In a multithreaded, hosted userspace program the wait operations should synchronize with another thread. This involves inserting optimization barriers that are understood by the compiler, therefore it can't optimize the this case to always return 0.

O(nlogn) is probably reasonable. Why break up a long function then if you are experiencing O(nlogn) scaling of compile time on function size?