They told everyone about it by mentioning it in both of the first two links in the summary, in addition to the New Features page linked to in another comment.

Me too. The customer service lady made a big fuss about it, and was shocked that I would return a DVD in an opened box, and was even more shocked when the entertainment department told her to just give me my money back. She did so, but hesitantly, and it left me with a bitter aftertaste. I did not have a separate DVD player, so the disc really was completely useless for me.

Other shops don't make me worry whether they'll let me return a defective product, they do, so they've lost me as a customer.

Note that on 32-bit systems, btrfs will only work well until your inode numbers no longer fit in a 32-bit int, which unlike with other file systems can easily happen. stat() will return an error code, and critical things like the ELF loader will no longer work.

Yes, I've seen this happen.

Nope, sorry, not true. Parameter names never conflict with identifiers in any other scope.

They conflict with macros. Users are allowed to define macros before including standard library headers, and often do. I'm not familiar with GNU C coding standards, so you may have a point that __len should be _Len according to that, but as far as the C standard and POSIX care, either is fine.

Which would be fine, except that the glibc man pages don't say which functions are from which standard,

glibc doesn't include man pages, so firstly, your complaint isn't with glibc, and secondly, the ones on my system, as provided by man-pages, do. For example, from `man send`:

CONFORMING TO
4.4BSD, SVr4, POSIX.1-2001. These function calls appeared in 4.2BSD.
POSIX.1-2001 only describes the MSG_OOB and MSG_EOR flags. The MSG_CONFIRM flag is a Linux extension.

If a function comes from 4BSD but was later adopted by POSIX and SUS, what do you define?

If you're writing in the POSIX subset of glibc, you define the POSIX macro.

If you define the POSIX macro, then you may find that you've suddenly hidden a load of other things that were working correctly.

So you're not limiting yourself to POSIX anyway, and the problem isn't glibc's POSIX support, it's how to combine POSIX with glibc extensions.

There are some really fun cases where no combination of the public macros expose all of the features that you want and you need to define some of the glibc internal ones.

_GNU_SOURCE should make everything from glibc available. What are you using that isn't exposed by this macro?

Unfortunately for developers, Debian GNU/kFreeBSD uses GNU libc, rather than FreeBSD libc, so you get all of the fun of working with a libc written by someone who can't read the C standard (see unistd.h and its use of reserved identifiers for inline function parameters)

Well duh! Of course libc uses reserved identifiers for those. If it used non-reserved identifiers, it would conflict with valid user code.

and requires a huge mess of -D flags to compile POSIX / SUS code.

It requires one or more of the macros that, according to POSIX / SUS, the code needs to define. If the code (for convenience I'll include the build system in "code") doesn't define those macros, but does make use of POSIX functions, that's already a bug in the code.

Personally however, I think any judge would see through that and realize that the electronic ability to distribute only the modified part of a work doesn't change the intent to distribute a modified work itself.

If I publish an unauthorised errata for a paper book, would you expect me to get convicted of copyright infringement?

BTW, does the C standard demand that all integer types use the same representation?

The C standard almost requires that the corresponding signed and unsigned types have the same representation for non-negative values within the signed type's range, so you probably won't see a little-endian signed int and a big-endian unsigned int even on specially created weird archs, but other than that, anything goes. ("Almost requires": it doesn't actually require it, but there are a few ways where the standard allows you to read a signed value using an unsigned type or vice versa, so if the representations differ, some sort of type tagging is needed.)

If not, one could imagine that e.g. char uses signed magnitude, short uses ones complement, and long uses twos complement.

As far as I know, that does not violate any of C's rules.

The C standard says a char is one byte, but does not say one byte is one octet. It allows for 16-bit bytes, which of course also means 16-bit chars. Speaking of weird archs, omething I'm experimenting with myself is enabling alignment checks on x86 (x86-64 only right now; x86-32 causes too many problems); a large number of packages have no problems whatsoever with it, and of those that do, most of it comes from "if x86 then don't bother with alignment" logic, which is easily disabled.

Technically, yes, the protocol of a URL is required, but that's because a URL is a form of an absolute URI, and absolute URIs are those that include the protocol. Relative URIs are perfectly valid. The protocol is required in an absolute URI. If it is omitted, it's a relative URI. This is not the browser making assumptions, this is how URIs are defined.

Really? How many different places do you routinely need access to?