People will use the most outlandish claims to make them and others feel better about themselves and expect you to go along to not shatter there carefully created painting of reality
Undefined behavior is not the same as implementation-defined or unspecified behavior. A program with undefined behavior is by definition an incorrect program. But there are cases where the spec actually gives some margin to the implementation. Programs relying on the choices of the implementation may be correct, even if non-portable.
>A program with undefined behavior is by definition an incorrect program.
This is simply false and an oft repeated myth. Undefined behavior has a specific technical definition that is in the C++ standard [1] and there is absolutely no mention in that definition or the implication of that definition that undefined behavior necessarily results in an invalid or incorrect program.
The definition of undefined behavior, right from the standard itself is... and I quote... get ready for it...
"behavior for which this document imposes no requirements"
That's it, nothing more, nothing less.
The standard even goes out of its way to state the following:
"Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, *to behaving during translation or program execution in a documented manner* characteristic of the environment".
Behaving in a documented manner characteristic of an environment is a far cry from being by incorrect by definition.
>This document imposes no requirements on the behavior of programs that contain undefined behavior
That's saying that programs that exhibit undefined behaviour are not governed by the C++ spec. For a program to be a valid, spec governed piece of C++ code it has to exhibit no undefined behaviour (outside of some constraints). Its accurate to say that any undefined behaviour results in the code being executed no longer being C++, and it can have any behaviour. That's synonymous in common developer speak with 'incorrect', as its desirable for your C++ code to be executed as C++
If the C++ standard imposes no requirements on such a program, then that means that the program is not C++. It's quite reasonable to describe such a program as an "incorrect [C++] program."
This is a semantic quagmire, and the threads on what undefined behaviour is are interminable. But just note this time around that correctness is not the same as conformity.
What's the difference? There's no such thing as "incorrect C++, but still C++." A program is either correct/valid/conforming C++, or it's not. We can reasonably describe "not" as "incorrect," or "invalid," "nonconforming," or just "not C++."
Do I love selective quoting! "Undefined behavior may be expected... when a program uses an incorrect construct or invalid data". There is also "erroneous behaviour" which "is always the consequence of incorrect program code".
Honestly, you'd have a better argument by quoting that "Correct execution" can include undefined behavior and erroneous behavior, depending on the data being processed". Which is quite a wild sentence to read, but here we are.
PS: Did some research and while it is true that a ZWNBSP will break up ligatures in many systems, that’s not its intended use. It’s there to prevent line breaks (up to Unicode 3.2), nowadays only kept for compatibility outside of BOM. Modern Unicode uses U+2060 WORD JOINER to express the same intention.
The old Unicode rules for ZWNBSP are also quite tricky: you are not supposed to ignore the first ZWNBSP if you already know the encoding. Which means to express an initial actual ZWNBSP you need to write two of them if the encoding is unknown to the receiver and only one of them if known.
> Where the character set information is explicitly marked, such as in UTF-16BE or UTF-16LE, then all U+FEFF characters, even at the very beginning of the text, are to be interpreted as zero width no-break spaces. Similarly, where Unicode text has known byte order, initial U+FEFF characters are also not required and are to be interpreted as zero width no-break spaces. For example, for strings in an API, the memory architecture of the processor provides the explicit byte order. For databases and similar structures, it is much more efficient and robust to use a uniform byte order for the same field (if not the entire database), thereby avoiding use of the byte order mark.
Systems that use the byte order mark must recognize that an initial U+FEFF signals the byte order; it is not part of the textual content. It should be removed before processing, because otherwise it may be mistaken for a legitimate zero width no-break space. To represent an initial U+FEFF ZERO WIDTH NO-BREAK SPACE in a UTF-16 file, use U+FEFF twice in a row.
The first one is a byte order mark; the second one is the initial zero width no-break space.
No, it's only allowed at the start. How would that even work? If an app sees a UTF-32 BOM halfway through a file should it interpret the rest of the file as UTF-32? Are there any apps that handle text files like this?
The dots do help a little, but not much. I wouldnt use my phone for long while in a vehicle, though at the very least I no longer dread having to briefly read a text message if I have to.
I found your note on bad drivers interesting. For me, it's the quick acceleration, braking and turning that's the worst. A bit anecdotal, but I also experience car sickness less with women drivers. Maybe because they're usually easier on the acceleration and brakes?
I would be more interested if they are ever going to cancel HAN unification. Looking at their "Factors for Exclusion" list it could be summarized by "we made some mistakes in past but are sticking to it" :D
IVD works, theoretically and practically (recent versions of OpenType have an explicit support for them). It's not their fault that Japanese vendors have been not very quick to adopt them.
If a Japanese and Taiwanese person type things with their keyboards and end up with the same bytes for different logical characters then no things do not work practically for any practical definition of "practically".
Your argument is absurd because people don't see code---they see glyphs, and using the same code for slightly different glyphs is a non-issue when they are not interchanged. (And when they are interchanged, both would see glyphs "correct" to them anyway.) Japaneses are sensitive to Han unification only because they recognize more glyph variations (Z-variants) than what Unicode originally could, and IVS is exactly a tool for ensuring exact glyphs assuming cooperative vendors. Not to mention that Han unification was already quite weakened by source separation principles in the first place.
Chinese AI labs are reducing Japanese images and text out of AI models - they leave much smaller amount for text models that has to be literate in Japanese, and explicitly nuke it out of dataset for image models so that it only supports Simplified and English languages, so to avoid GIGO.
I mean, making or help making sovereign AI models is nowhere near responsibilities of Unicode, but Han Unification and sort of a default-enforced IVD support is literally adding small but non-zero amount of fuel to cultural division and xenophobia perpetuate in East Asia. I doubt blaming users would work here.
While I agree that Han Unification is not optimal (and fixing them is a welcoming development), it is already too late to reverse it. Even counter-proposals like TRON didn't work at all so far. IVD is the best compromise we can have in this situation.
> cultural division and xenophobia perpetuate in East Asia
By the way, I recently have seen multiple claims from Japanese Twitter users that Korea would have been better keeping Chinese characters (Hanja) in use. If this is a cultural division and xenophobia we are talking about, I will gladly take it---why on earth do they have any saying in Korea's choice of scripts? The "sinosphere" is an illusion, the fact that CJKV countries have or had shared the same set of characters is just a fun fact and not a cultural mandate or anything else like that.
> IVD is the best compromise we can have in this situation.
Maybe, but no one is running an ivdfy-filter through every single Japanese documents and the issue keeps going. Maybe one way to make it happen is to make the Simplified forms singularly canonical to the CJK Unified Ideographs so to classify everything in that form as Chinese, and define Japanese script as being always flagged with IVDs, though I don't know what the storage and processing implication of that might be. But my point is that maintaining the position that users can optionally choose to not display text in a wrong language and Unification issues are merely user errors don't make any sense to me.
> Korea would have been better keeping Chinese characters (Hanja) in use.
I can't speak for all, but I, for one, do regularly encounter machine translation failures in Korean contents due to homophones even with LLM-based ones in the ways that don't happen with Japanese. It manifests as either homonym errors[1] or the MTL resorting to phonetic transcripts that I have no idea about[2]. Both happens in formal writings like newspaper Web articles in addition to casual social media posts. Since it appears that there's no way this issue could happen with "our" system, it sometimes feel like reverting to that could fix it.
1: (like "plain/plane", had the source been English and this was somehow happening)
2: (like "That arm might be fukuzatukossetsushiteru" had the source been Japanese)
(update: looks like there was someone/some groups ragebaiting Korean and Japanese Twitter users with Korean transition into the Hangul phonetic script for Twitter impression incentives money. Those tweets had not reached me at the time of writing above comment, and my opinion that bringing back Kanji/Hanzi could solve some translation/communication issues is not based on whatever they used as fuels, though I fear it might have been actually close to it)
I need a table emoji because then I could combine it with a horse emoji. This would be "Pferd Tisch" (Horse Table) in German which sounds similar to "Fertig" which translates to "done". Yes I want it only for that dumb joke.
If the seahorse emoji is introduced, we will have to train new foundation models. The costs connected to the introduction of the seahorse emoji will be in the billions.
You're absolutely right—the seahorse emoji was added in Unicode version 19.0.0 after OpenAI purchased the Unicode Consortium and converted it to a for-profit corporation.
The double space after a period, with the added effort to avoid browser whitespace condensing, is an interesting style choice. Is it meant to mimic old academic publications?
While present in some of their previous articles sparingly, this is the first one to use it consistently.
THANK YOU. I was confused at the normalization example given, and had to think through it. (id, name, age) is already at 5NF, and the only one it doesn’t satisfy is 6NF.
Wait. Are you claiming that there's some sort of link between "Gates's relationship with financier Jeffrey Epstein started in 2011" and the Gates Foundation which launched in 2000 by merging with the Gates Sr. Foundation from all the way back in 1994?
