Somehow most of my portability issues seem to be caused by glibc, its symbol versioning and close ties to the dynamic loader. Minor versions aren't compatible, no two Linux distros ship the same version and you can't just provide your own without also patching in your own dynamic loader.
At least as far as the defaults on Linux go I consider C the root of all evil.
AFAIK glibc is backwards compatible as long as a) your program is running on a newer version (i.e. you're not trying to dynamically link against an older version) and b) you're not using hidden/undocumented symbols.
In which case as long as you're using the documented public API and compile your program with the oldest version of glibc you want to support (some Ubuntu from 4-5 years ago should cover pretty much every current desktop) you should be fine. And with something like Docker this is trivial to do.
Sure it is annoying that you cannot use your current distro (especially if you use some rolling distro) to make binaries for everyone, but it takes very little effort to work around that. The only issue i can think of is if you absolutely want to compile using the latest version of your compiler and you cannot build the compiler from source to work in the Docker (or whatever) contain to work against the older glibc.
In complex cases, it turns out that the old version of glibc also pulls in other libraries and the compiler, and you're stuck with a very ancient sysroot.
You may often find that you can't compile new library versions in such a sysroot and link them statically.
So, it looks good on paper, but forget about the ravines.
Any project depending on Integer identity had years of warning that this change would come. Also given implicit primitive conversions and object pooling Integer isn't exaclty a prime candidate for object identity to begin with.
Indeed, one useful thing you can do is fire questions like "I've got three different solutions to this problem, which performs best?". You don't need to keep the code, you just want to know which direction you should take.
I would say there is nothing descriptive about calling something American. America doesn't even refer to a single country, does it operate out of Brazil? Would that even be relevant information to anyone using an Airline?
At least the GL part isn't something that has a widely understood meaning and I don't think any of the competing APIs are generally refered to as Graphics Libraries either.
By default XML is either UTF-8 or 16, any other encoding has to be identified either through metadata or an explicit declaration in the document itself.
If you are guessing it is because someone failed to properly store or transmit the document.
By "through metadata", you mean with some external separate mechanism unrelated to the XML spec? That's exactly the flaw of what's supposed to be a universal and general document representation.
Both UTF-8 or UTF-16 are supported, yes, but that doesn't solve the problem because XML parsers have to deal with other encodings. A document that initially looks like UTF-8 could be almost any of literally hundreds of encodings including all the common ISO 8859 encodings. Which is why XML processing/parsing code has to go through multiple phases: a "try to determine the encoding" phase (using heuristics like those described in https://www.w3.org/TR/REC-xml/#sec-guessing) and then switch to a "parsing" phase after rewinding to the start of the document.
I did some work for a bank once which were in the process of moving to using XML as the universal messaging format (message bus architecture) and this wasn't some theoretical issue - it was a genuine pain as the message sources and sinks included a bunch of machines with different native encodings including a bunch of IBM machines (EBCDIC), old Windows machines, proprietary Unices like HPUX, along with Linux, etc.
> By "through metadata", you mean with some external separate mechanism unrelated to the XML spec?
The code generating the xml text may not be aware of the final encoding used to store/transmit it and a library writing text to an encoded stream might not be aware that the text it is sending contains xml. So I would say allowing xml to be parsed using an externally specified encoding makes at least some sense.
> A document that initially looks like UTF-8 could be almost any of literally hundreds of encodings including all the common ISO 8859 encodings
Your own link shows that those "hundreds of encodings" are all based on ASCII, which is enough to get the concrete encoding from the declaration.
> and then switch to a "parsing" phase after rewinding to the start of the document.
reply