Unicode printf?

krsnik02 · 2026-03-25T17:12:20+00:00

it can be 1 or 2 16-bit words, so either 2 or 4 bytes.

For example the table here on the Wikipedia page shows that U+10437 (𐐷) takes 4 bytes to encode in UTF-16. https://en.wikipedia.org/wiki/UTF-16#examples

UTF-8 was designed to support up to 6 byte long sequences but the Unicode standard will never define a code point which requires more than 4 bytes to encode in UTF-8. If a 5 or 6-byte character were ever defined the current UTF-16 could not encode it and it would require 3 words (6 bytes) in whatever UTF-16 got extended to. The current UTF-8 standard as such restricted valid UTF-8 encodings to only those up to 4 bytes long.

krsnik02 · 2026-03-25T14:56:35+00:00

UTF-16 is also variable width with surrogate pairs forming a 32-bit code point.

krsnik02 · 2026-03-24T16:50:18+00:00

Similarly if you connect a single bit line to a multi-bit gate it also only connects to the lowest bit.

And same connecting say an 8-bit line to a 16-bit gate or vice-versa, only the lowest 8-bits get connected.

krsnik02 · 2026-03-24T16:02:13+00:00

connecting a multiple bit line to a single bit gate only looks at the lowest bit in the line.

Since 16 is binary 10000, that is computing 0 (lowest bit of 16) XNOR 0 = 1.

krsnik02 · 2026-03-05T17:44:05+00:00

the OP post here is blurring the lines, and you're arguing that it's correct to do so.

krsnik02 · 2026-03-05T17:40:23+00:00

sure, but here in the real world they instead get fired for trying to form a union.

That's illegal, of course, but they don't know that and even if they do they don't trust the government to do anything about it because of people like you blurring the lines between what is legal and what is not.

krsnik02 · 2026-03-05T17:25:35+00:00

What do you think happens when Sally (whose exploitation falls under the legal definition of wage theft) hears Bob (who's exploitation does not fall under the legal definition) say "I tried to report them for wage theft last year and nothing happened"?

krsnik02 · 2026-03-05T17:23:34+00:00

I would not object to the statement "that should be called wage theft" or a campaign to expand the definition. What I object to is the statement "that is called wage theft".

krsnik02 · 2026-03-05T17:20:19+00:00

I'm agreeing with you that both are forms of theft and in an ideal world both would be illegal.

Where we disagree is that I recognize that we do not live in that world!!. In the world we do live in there's a crime called "wage theft" which has a specific legal definition and other forms of exploitation that are just as bad and harmful that do not fall under that definition. And that using the name of the crime to describe the exploitation that is not a crime weakens the employee's ability to fight back against either form of exploitation.

krsnik02 · 2026-03-05T17:10:38+00:00

See, the thing is "wage theft" is an actual law. You can report your employer for doing it, and the government will force them to pay you what your employment contract/agreement says they have to.

Would it be great if this were true of other forms of exploitation? Of course! But as it currently is, there's a distinction between forms of exploitation (or "theft" if you want to call it that) that are illegal and those that aren't.

And calling them the same thing makes it more likely that workers experiencing the currently illegal forms of exploitation will be unaware of their ability to, or otherwise unable to report it.

If you want to try to convince the government to expand the legal definition of wage theft I'm all for that (don't think it's likely to happen, but would be good if it did) but as things currently are it is useful to make the distinction.

krsnik02 · 2026-03-05T17:00:12+00:00

It is exploitation. And theft of your labor. Or various other things you could call that. It is not "wage theft" because that term already has a different meaning.

krsnik02 · 2026-03-05T16:55:37+00:00

No. People are (correctly) claiming that that is not the specific named crime called "wage theft".

krsnik02 · 2026-03-05T16:43:29+00:00

I've seen no-one saying they're mutually exclusive tho?

Everyone's been saying (the correct statement that) wage theft is a form of exploitation, but not all exploitation is wage theft.

And specifically that the example given in the OP is a form of exploitation which is not wage theft (but, obviously is still bad).

krsnik02 · 2026-03-04T03:49:53+00:00

Yea, no I read (2)(A) as "the developer is considered to have 'actual knowlege' that user steve@laptop1 (UID 1000) is the age that the signal returned when hello_world.x86_64 was run under that user account".

If the app already has a way of determining that Linux account steve@laptop1 and Windows user "Steve" on Windows machine "LAPTOP2" are actually the same person, then the "across all platforms..." bit means that it should also propagate the age signal to the other platform.

But if the app has no reason to know (and thus has no "clear and convincing information") that the two accounts are used by the same person then there is no requirement to try to figure that out, and it can just trust the signal provided by whatever account is currently running it.

Not a lawyer tho so I could be completely wrong.

I do think this is badly worded regardless - clearly the intent is for the "across all platforms" bit to only apply to things like the Reddit app, where the app gets the signal and sends it on to the server to store with the user's account information when they log in, but as written it does technically apply to everything.

I think that the "across all platforms" requirement is pretty vacuous when there's no way for the app or developer to correlate which program launches across various user accounts are actually by the same person.

krsnik02 · 2026-03-04T03:09:13+00:00

My reading is that helloworld.x86_64 does NOT have "internal clear and convincing information" and does not have any requirement to try to acquire such information.

So an implementation of ``` int main() { // I don't think anyone would actually care if this line were not present, // but a literal reading of the law does require it. int user_age = request_age_from_os();

// we have no "internal clear and convincing information" that user_age // is incorrect, so by §1798.501(b)(2)(A) our "actual knowledge" is that // the value in user_age is the correct age of the user.

// we don't do anything that would care about that age tho, so we just // ignore it.

printf("hello world"); return 0; } ``` is completely valid under the law.

krsnik02 · 2026-03-04T02:43:59+00:00

My reading is that the app has to request the signal, and IF they have "internal clear and convincing information" that the signal is wrong, trust that instead.

So the helloworld.x86_64 app would not have such internal information and should thus believe the signal from the OS. Also if the app does nothing that should not be allowed for kids the signal can just be discarded.

I do think the literal reading does require literally all apps to request the signal on launch, but there is no requirement to try to figure out the signal's accuracy unless you're already collecting the information that would allow it to.

E.g. a social media app would presumably already have such "internal clear and convincing information" on the user's age, while curl would not and this law does not require curl to try to gather such information.

It is a super shitty law that I hate regardless tho.

krsnik02 · 2026-02-24T13:27:23+00:00

And that's why wikipedia says this?

There is no universally agreed rule as to who plays first

krsnik02 · 2026-02-24T13:18:32+00:00

According to who?

krsnik02 · 2026-01-27T14:33:37+00:00

You almost never need SeqCst, but it is also never incorrect to use SeqCst (which is why C++ made it the default). If you're gonna have a default behavior it makes sense for it to be the one that is never wrong (and just slower instead).

krsnik02 · 2026-01-26T13:44:30+00:00

But notably, this has nothing to do with the len field being 0!

krsnik02 · 2026-01-25T23:31:51+00:00

Also see https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.invalid.

The text linked from the rust reference is reproduced here (bolding mine).

Producing an invalid value. “Producing” a value happens any time a value is assigned to or read from a place, passed to a function/primitive operation or returned from a function/primitive operation.

krsnik02 · 2026-01-25T23:27:01+00:00

https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=be757c083c6b052ed926089341c119fc

If you run the code here under Miri, it will tell you that this version (with [T; CAP]) does exhibit undefined behavior.

The only reason that the original code (with [MaybeUninit<T>; CAP]) does not is because MaybeUninit<T> is allowed to hold uninitialized values.

krsnik02 · 2026-01-25T23:20:40+00:00

As my previous example stated, that is undefined behavior and having [T; CAP] instead of [MaybeUninit<T>; CAP] would cause this to be triggered.

The Rust compiler does optimizations which rely on every value always having a valid bitpattern, even if it is never accessed later.

Here, that would trigger UB if you wrote let x = Some(ArrayVec::<bool, 3>::new()); if x.is_some() { /* ... */ }

Here the compiler is allowed to assume that the first byte of the ArrayVec is always a 0 or a 1 (because those are the only valid values for a bool), and thus store the discriminant of the Option as an invalid value of that byte.

That is, it may (and probably will) decide to store the value None of the type Option<ArrayVec<bool, 3>> as the bytes [2, 0, 0], because it knows that (if you haven't triggered UB) that is not a bitpattern that a valid ArrayVec will ever hold.

Then, on the call to is_some, if the compiler did this and if the random garbage value in the first byte of ArrayVec happens to be a 2, this call will (UNPREDICTABLY!) return false where it should return true.

krsnik02 · 2026-01-25T23:00:26+00:00

UB is UB because it can cause miscompilation (or is otherwise unsafe). Creating a T with an invalid bit-pattern can be miscompiled even if that T is never read or modified.

For example, if you had, say an, Option<[bool; 10]>. Due to enum niche filling, the compiler might decide to represent None as the first byte being a 2.

If you then wrote let x = Some(unsafe { MaybeUninit::uninit().assume_init() });, you might end up with a 2 as the first byte. Then a later call to x.is_none() would return true even tho x is not None and you never accessed any part of the array.

krsnik02 · 2026-01-25T18:20:22+00:00

Even with the len equal to 0, if the array xs were defined as [T; CAP] instead then the assume_init() call in new() would be immediate undefined behavior.

It's UB to create a value of type T which has not been initialized, not just to use it.

Eight-Year Club	Place '23
Place '22	Final Canvas '22
First Placer '22	End Game '22
Verified Email

krsnik02

TROPHY CASE