That's POSIX, not the C language standard. https://www.iso-9899.info/n1570.html#7.31 lists the library API names reserved for future use; section 7.1.3 in the same document states explicitly that they are reserved.

It's not that the word "island" has any particular significance; it's that all names starting with "is" followed by a lowercase letter are reserved (in external linkage and in the global scope of files that #include <ctype.h>), so that future versions of the language can add more standard library functions along the lines of isalpha, isdigit, etc., without making the current standards committee guess in advance which specific names following that pattern their successors might want to add in the future, and without breaking existing code. (Unless that existing code ignores these rules, which seems to be fairly common in practice.)

The C is of course a pirate's favorite language. It might end up with "water" and "land" types in the standard some day. So `bool iswater()` and `bool island()` functions might be needed! You might need to check if the island structure you got is really land, so `island(&possible_island)` would obviously help and not cause any confusion to readers of the code.

Aye, any pirate's first love be the C

You might want to know if you have a small piece of land surrounded by water, so we need

  isisland(x);

Or to know if an element is a member of a particular terror group (or an Egyptian goddess):

  isisis(y);

And if you want to know if some territory is claimed by a particular terror group (or Egyptian goddess, or post-metal band) there is the venerable

  isisisland(z);

In this case you'd typically then construct a memory fence.

You just have to pass the pirate flag to your compiler

I think you’ll find it’s actually called an arrgument

Of course depending on how locale is set will effect the results of island() and iswater()

I saw someone point out that these identifier restrictions mean that a valid C compiler optimization would be to change all instances of "x = to[a-z]+(y);" to "if (!is[a-z]+(y)) x = to[a-z]+(y);" Not that any compiler would actually be absurd enough to implement this, of course :)

Naturally, this would imply the validity of the optimization:

x = toilet(y); -> if (!isilet(y)) x = toilet(y);

Only if you've included <ctype.h> or <wctype.h> though.

They could just generate a random string, making it extremely unlikely that it will conflict with an existing name. And it won't be any less descriptive than most existing names in the C standard library.

Note that the original post is not up to date with the C23 developments on the subject, wherein the standards people appear to have noticed that nobody has ever cared about overbroad reservations like str*, is*, to*, and E*, and introduced a notion of “potentially reserved identifier” that I have so far been unable to understand. The relevant paper, “What we think we reserve”[1], has been folded into the draft standard.

[1] https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2625.pdf (I hope that’s the right version)

Basically, the wording is so that they can advise implementations to complain on potentially invalid-in-the-future uses of "potentially reserved identifiers", but invalid uses of actually reserved identifiers are still "requires no diagnostics". They feel that allows them to extend the already way too vast amount of reserved identifiers even further without any reservations.

Yes, that means that an implementation will warn you that your code might break in the future, but on the day when it actually breaks, it will just stop complaining. Why they could not just mandate detecting invalid uses of reserved identifiers is beyond me.

On the page you linked, you can see that `ctype.h` reserves all prefixes of `is[a-z]` and `to[a-z]`, and `string.h` reserves `str[a-z]`. These come from the C standard (in C99, it's 7.26 "Future Library Directions"), though I don't think they use the word "reserved" there.

The "reserved" bit is from section 7.1.3:

> Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

He says where they come from -- section 7.31 of the C11 standard[1]. For example, in 7.31.12:

> Function names that begin with str and a lowercase letter may be added to the declarations in the <stdlib.h> header.

Or 7.31.13:

> Function names that begin with str, mem, or wcs and a lowercase letter may be added to the declarations in the <string.h> header.

So according to the standard, if your code #includes string.h, it may conflict with a future version of the standard if you use names like "strong" or "memorize". This is extraordinarily unlikely, though.

[1] https://port70.net/~nsz/c/c11/n1570.html#7.31

These strings are included in the regexes given just about that line as reserved for potential future by certain header files. "island" is covered by the ctype.h and wctype.h headers, which reserve every word starting with "is".

One of these situations where “I don’t make the rules” is a fit one liner.