> If you want to pretend this never happened – delete your old article and post the new one you have promised. And I will not write “an OSINT investigation” on your Nazi grandfather
Their direct internet connections rarely go down, but links between servers in their internal network suffer from intermittent failures. if you make your service reliable enough to be able to run on a single node, you could have built a monolith in the first place.
If you build microservices you should always assume that links go down! So what is the deal here? Think about it as a feature to make your application more error prone. :-)
I think this is short-sighted - there are many applications where a single node is all one needs, and this is a huge part of Hetzners user base, presumably.
A bit of anecdote from me, as a decades-long Hetzner user: I have personally felt no real impact whatsoever with their internal network suffering from intermittent failures. The downtime incurred by Hetzner admin I've experienced is measured in minutes, in my case over a 10 year period as a customer...
Various macro tricks have existed for a long time but nobody has been able to wrap the return statement yet. The lack of RAII-style automatic cleanups was one of the root causes for the legendary goto fail;[1] bug.
To be fair, there were multiple wrongs in that piece of code: avoiding typing with the forward goto cleanup pattern; not using braces; not using autoformatting that would have popped out that second goto statement; ignoring compiler warnings and IDE coloring of dead code or not having those warnings enabled in the first place.
C is hard enough as is to get right and every tool and development pattern that helps avoid common pitfalls is welcome.
The forward goto cleanup pattern is not something "wrong" that was done to "avoid typing". Goto cleanup is the only reasonable way I know to semi-reliably clean up resources in C, and is widely used among most of the large C code bases out there. It's the main way resource cleanup is done in Linux.
By putting all the cleanup code at the end of the function after a cleanup label, you have reduced the complexity of resource management: you have one place where the resource is acquired, and one place where the resource is freed. This is actually manageable. Before you return, you check every resource you might have acquired, and if your handle (pointer, file descriptor, PID, whatever) is not in its null state (null pointer, -1, whatever), you call the free function.
By comparison, if you try to put the correct cleanup functions at every exit point, the problem explodes in complexity. Whereas correctly adding a new resource using the 'goto cleanup' pattern requires adding a single 'if (my_resource is not its null value) { cleanup(my_resource) }' at the end of the function, correctly adding a new resource using the 'cleanup at every exit point' pattern requires going through every single exit point in the function, considering whether or not the resource will be acquired at that time, and if it is, adding the cleanup code. Adding a new exit point similarly requires going through all resources used by the function and determining which ones need to be cleaned up.
C is hard enough as it is to get right when you only need to remember to clean up resources in one place. It gets infinitely harder when you need to match up cleanup code with returns.
In theory, for straight-line code only, the If Statement Ladder of Doom is an alternative:
int ret;
FILE *fp;
if ((fp = fopen("hello.txt", "w")) == NULL) {
perror("fopen");
ret = -1;
} else {
const char message[] = "hello world\n";
if (fwrite(message, 1, sizeof message - 1, fp) != sizeof message - 1) {
perror("fwrite");
ret = -1;
} else {
ret = 0;
}
/* fallible cleanup is unpleasant: */
if (fclose(fp) < 0) {
perror("fclose");
ret = -1;
}
}
return ret;
It is in particular universal in Microsoft documentation (but notably not actual Microsoft code; e.g. https://github.com/dotnet/runtime has plenty of cleanup gotos).
In practice, well, the “of doom” part applies: two fallible functions on the main path is (I think) about as many as you can use it for and still have the code look reasonable. A well-known unreasonable example is the official usage sample for IFileDialog: https://learn.microsoft.com/en-us/windows/win32/shell/common....
I don't see this. The problem was a duplicate "goto fail" statement where the second one caused an incorrect return value to be returned. A duplicate defer statement could directly cause a double free. A duplicate "return err;" statement would have the same problem as the "goto fail" code. Potentially, a defer based solution could eliminate the variable for the return code, but this is not the only way to address this problem.
This has the exact same bug: the function exits with a successful return code as long as the SHA hash update succeeds, skipping further certificate validity checks. The fact that resource cleanup has been relegated to defer so that 'goto fail;' can be replaced with 'return err;' fixes nothing.
I don't think so. The value is set in the assignment in the if statement even for the success path. With and without defer you nowadays get only a warning due to the misleading indentation: https://godbolt.org/z/3G4jzrTTr (updated)
No it wouldn't. 'err' is declared and initialized at the start of the function. Even if it wasn't initialized at the start, it would've been initialized by some earlier fallible function call which is also written as 'if ((err = something()) != 0)'
I'm sick of corporations and bootlickers who claim you cannot do games without anticheats. Even if I am not personally running that software, all the users are still normalizing spying on our devices and networks.
If your business model relies on violating the privacy of others, your business deserves to die.
I had subscribed to clearance sale newsletters from quite a few retailers but unsubscribed when I noticed they put stuff in the outlet section only when they run out of sizes S to L.
My main gripe with UB is that if a compiler is able to detect undefined behavior invocation, it is still allowed to compile (or rather omit) said code instead of crashing.
> vibe coded software with major security vulnerabilities
> vibecoded without reading any of the code
Remember when years ago people said using AI for critical tasks is not an issue because there is always a human in the loop? Turns out this was all a lie. We have become slaves to the machine.
A certain automation system vendor uses proper USB license dongles in their PC software but they do not do challenge-response authentication. Instead they send a hardcoded string to the dongle and compare the response against a list that contains various software feature levels.
The whole automation system including machinery costs anywhere from 200k to 1M yet Vendor™ tries to milk the customers dry with a 1.5k software license that lets you manage up to 254 physically* connected systems. I'm pretty sure the license dongle is in reality designed to prevent casual tinkering of parameters, which is something only service techs should do.
*You can circumvent this with serial-over-Ethernet converters, which has resulted in an Industrial Internet of Shit-level security nightmare as companies happily expose their systems over the internet, thinking that license dongles are a substitute for authentication.
From hero to a Kremlin troll in five seconds.
reply