> "this test failure is preexisting so I'm going to ignore it"

Critical finding! You spotted the smoking gun!

I would say that this is limited to a targeted Go version and architecture. For example, the filter checks for the goroutine pointer on `r28` which is correct for arm64 but not universally true.

Any changes to the struct layouts, stack, or heap layouts would also cause failures in these lookups. E.g., in Go 1.17, many functions now use direct register mappings for arguments rather than always placing arguments in the stack.

Would need to thoroughly vet compatability with each new Go version before using something like this in production.

You’ll probably want to look to the PEPs. Havent dug into this topic myself but looks related https://peps.python.org/pep-0744/

I think CPython already had tier2 and some tracing infrastructure when the copy-and-patch JIT backend was added; it's the "JIT frontend" that's more obscure to me.

I'd say a lot of users are going to borrow patterns from Go, where you'd typically check the error first.

    resource, err := newResource()
    if err != nil {
        return err
    }
    defer resource.Close()

IMO this pattern makes more sense, as calling exit behavior in most cases won't make sense unless you have acquired the resource in the first place.

free may accept a NULL pointer, but it also doesn't need to be called with one either.

This example is exactly why RAII is the solution to this problem and not defer.

I love RAII. C++ and Rust are my favourite languages for a lot of things thanks to RAII.

RAII is not the right solution for C. I wouldn't want C to grow constructors and destructors. So far, C only runs the code you ask it to; turning variable declaration into a hidden magic constructor call would, IMO, fly in the face of why people may choose C in the first place.

defer is literally just an explicit RAII in this example. That is, it's just unnecessary boiler plate to wrap the newResource handle into a struct in this context.

In addition, RAII has it's own complexities that need to be dealt with now, i.e. move semantics, which obviously C does not have nor will it likely ever.

> RAII has it's own complexities that need to be dealt with now, i.e. move semantics, which obviously C does not have nor will it likely ever.

In the example above, the question of "do I put defer before or after the `if err != nil` check" is deferred to the programmer. RAII forces you to handle the complexity, defer lets you shoot yourself in the foot.

Thats interesting. If you’re on Chrome I’d try out Firefox just to see. I haven’t had any issues for a long time.

I find it better to bubblewrap against a full sandbox directory. Using docker, you can export an image to a single tarball archive, flattening all layers. I use a compatible base image for my kernel/distro, and unpack the image archive into a directory.

With the unpack directory, you can now limit the host paths you expose, avoiding leaking in details from your host machine into the sandbox.

bwrap --ro-bind image/ / --bind src/ /src ...

Any tools you need in the container are installed in the image you unpack.

Some more tips: Use --unshare-all if you can. Make sure to add --proc and --dev options for a functional container. If you just need network, use both --unshare-all and --share-net together, keeping everything else separate. Make sure to drop any privileges with --cap-drop ALL

Maybe it's a mix of me using the site less, or questions I previously answered not being as relevant anymore, however as it stands, it's just not fun to visit the site any more.

I have about ~750 answers and 24K rep after almost 12 years of being a member. The site was a great way to spend some free cycles and help people. My favorite bounty answer lead to me finding a bug in the Java compiler! I even got recruited into my current role from the old Stack Overflow Jobs board.

With AI, not only did the quality and frequency of posts go down, but the activity on my existing posts are basically zero now. I used to have a few notifications a week with either comments on my past answers/questions or a few upvotes (for those fun little serotonin boosts). Looking at my past stats.. in 2023 I had ~170 notifications, in 2024 that dropped to ~100, and in 2025 it went down to ~50 (with only 5 notifications since September).

I don't feel engaged with the community, and even finding new questions to answer is a struggle now with (the unanswerable) "open-ended questions" being mixed into the normal questions feed.

> Maybe once every four years on leap day or something.

Advantage: You no longer need to fix that leap day bug on your website.

would it be better to start the intentional shutdown at say a couple of minutes before midnight so you know the shutdown wasn't perhaps caused by the leap day bug?

I do the same, but I skip rsync for git.

    git clone $uri dotfiles; export HOME=$(pwd)/dotfiles 

These days, my laptop acts as a dumb SSH gateway for Linux VMs. No configuration or setup, aside from VS code connecting to VMs. Any server that I would want to load my dotfiles onto will almost always have git installed.

Rant (not directed at any comment here): If it's a production server without git, then please do not run scripts like this. Do not create junk directories on (or ideally any modifications to) secure machines. It inevitably causes new and uninteresting puzzles for your colleagues. Create documented workflows for incident responses or inspection.

Auto has really made c++ unapproachable to me. It's hard enough to reason about anything templated, and now I frequently see code where every method returns auto. How is any one supposed to do a code review without loading the patch into their IDE?

I'd suppose this really depends on how you are developing your codebase but most code should probably be using a trailing return type or using an auto (or template) return type with a concept/requires constraint on the return type.

For any seriously templated or metaprogrammed code nowadays a concept/requires is going to make it a lot more obvious what your code is actually doing and give you actually useful errors in the event someone is misusing your code.

I don't understand why anyone would use auto and a trailing return type for their functions. The syntax is annoying and breaks too much precedent.

Generally, you don't. I'm not sure why the parent suggested you should normally do this. However, there are occasional specific situations in which it's helpful, and that's when you use it.

It just is an improvement for a bunch of reasons.

1. Consistency across the board (places where it's required for metaprogramming, lambdas, etc). And as a nicety it forces function/method names to be aligned instead of having variable character counts for the return type before the names. IMHO it makes skimming code easier.

2. It's required for certain metaprogramming situations and it makes other situations an order of magnitude nicer. Nowadays you can just say `auto foo()` but if you can constrain the type either in that trailing return or in a requires clause, it makes reading code a lot easier.

3. The big one for everyday users is that trailing return type includes a lot of extra name resolution in the scope. So for example if the function is a member function/method, the class scope is automatically included so that you can just write `auto Foo::Bar() -> Baz {}` instead of `Foo::Baz Foo::Bar() {}`.

1. You're simply not going to achieve consistency across the board, because even if you dictate this by fiat, your dependencies won't be like this. The issue of the function name being hard to spot is easier to fix with tooling (just tell your editor to color them or make them bold or something). OTOH, it's not so nice to be unable to tell at a glance if the function return type is deduced or not, or what it even is in the first place.

2. It's incredibly rare for it to be required. It's not like 10% of the time, it's more like < 0.1% of the time. Just look at how many functions are in your code and how many of them actually can't be written without a trailing return type. You don't change habits to fit the tiny minority of your code.

3. This is probably the best reason to use it and the most subjective, but still not a particularly compelling argument for doing this everywhere, given how much it diverges from existing practice. And the downside is the scope also includes function parameters, which means people will refer to parameters in the return type much more than warranted, which is decidedly not always a good thing.

1) consistency, 2) scoping is different and can make it a significant difference.

I have been programming in C++ for 25 years, so I'm so used to the original syntax that I don't default to auto ... ->, but I will definitely use it when it helps simplify some complex signatures.

Consistency (lambdas, etc.)

it makes function declarations/instantiations much more grep-able.

Same in Java and Kotlin, but then again, the majority of people who write code wouldn't understand what I mean when I say "whether a collection is returned as List or Set is an important part of the API 'contract'".

The pain of lisp without any of the joy.