You can also just pull the USB drive out, if you have waited a reasonable time after last writing to it, no harm will be done.

Also, terminal commands have the advantage that they are the same over the course of 20something years and across all desktop environments, while the tinyfloppy windows moves critical functions around with every second patch so you have to relocate stuff you had just memorized.

Fuck Nestle.

is this “AI” you speak of in the room with you right now? If you believe that machine-learned pattern recognition and word prediction algorithms are “AI”, you shouldn’t be left anywhere near a compiler or production code.

That’s like asking the world’s best FPS gamers to “just try an aimbot”. Actual programmers do far better than a machine-learned bullshit printer.

So, I vibe-coded a new one

“I love to enable oligarchs and fascists”

it appears I have to make Tor my baseline browser :( lot’s of stuff that doesn’t require tor-connections, too - so it’s gonna feel like a dial-up modem again. Fuck LLMs

Partially true, yes, that is a downside: codeberg currently does not allow non-free licenses. But no, a repository does not have to be public.

You don’t need git alternatives. git has nothing to do with fascistsoft. Please don’t confuse a repo hosting service with the (FOSS) tools used thereon.

Alternative for github: codeberg.org

Don’t blame this on gcc or the library/function author - it is 100% user (i.e. programmer) error. Uninitialised memory of any type is undefined behaviour in the C and C++ abstract machine. That means optimising compilers can assume it does not exist.

I absolutely do blame this on the C++ standard being not specific enough, specifically for the way in how I learned about this: When writing a trivial function, you would never expect that - for a bool parameter - an “if (b)” branch can be executed as well as an “if (!b)” branch.

So basically, this mechanic sabotages input data validation in functions that test whether plausible parameters were provided. The problem is that a function you write that is bug-free and “perfect code” - despite input data validation - can exhibit undefined behavior due to an uninitialized bool type parameter. Something that can not happen with other uninitialized trivial (numeric) data types (int, float). Simply due to the way boolean checks are translated to x86 assembly:

Here’s an example: https://godbolt.org/z/T3f9csohd

Note the assembly lines 176-182: The only difference for the “if (!b)” check is that the lowest bit of the boolean is flipped with an xor - which assumes about the implementation that a boolean can never hold values other than 0 or 1. Which I - as a naive user - also assumed until this happened. Correction: I assumed that negating a bool would result in the inverse boolean value.

So the problem boils down to: The value range of any given (built-in) numerical data type fully encloses the value range that an uninitialized variable of that type can have. This is not necessarily true for boolean: In g++, the value range is [0;1] and the range of an uninitialized bool is [0;255].

Accordingly, I would expect the C++ standard to fix this by stating that an uninitialized bool must have a value for which only one of two conditions evluates to true: b or !b, but not both.

Been there, found undefined behavior where there should not be any. Imagine a function that takes a bool param with the following code, but neither branch gets executed:

if (b)
   doStuffForTrue();
if (!b)
   doStuffForFalse();

In a function that is passed an uninitialized bool parameter, in gcc compiler, both branches can get executed even when b is const. Reason: uninitialized bool in gcc can have values of a random integer, and while if(b) {} else ({} is guaranteed to execute only one branch, bool evaluations of a bool value take a “shortcut” that only has defined behavior with an initialized bool.

Same code with an uninitialized integer works as expected, btw.

One way to contribute to FOSS is to improve bad documentation. You are correct, of course, and lazy devs write bad code if they do not cultivate good documentation - imho.

now that is interesting. I assume MTK here means “MediaTek”?

Have you had any luck unlocking the bootloader without a windows computer to execute the xiaomi unlock tool on?

Well - if you get another response requiring action, maybe the first email wasn’t thorough enough :P

Read the thread again, it seems you slipped somewhere. This was all about the claim that implicit conversion to string somehow could make sense.

Also, you contradicted yourself just then and there. Not a single of your examples does string concatenation for these types. It’s only JS

C# is filthy. But it explains where you got your warped idea of righteousness.

You are entitled to your opinion. implicit conversion to string is not a feature in most languages for good reasons.

I don’t think there’s a way to retrofit JS - but php versions are deprecated all the time. Why not do the same with client-side script versions? :)

Why would you need an entirely different way of concatenating strings? “11” + 1 -> exception. “11” + to_string(1) = “111”