I mean, de facto, if Windows isn't good at it, at the very least compilers will have a "never mind ignore this" option if they even do start enforcing them. And while Raymond Chen knows Windows and can speak to it, I'd bet the Linux kernel has plenty of violations of this, and it's the same thing; no future C compilers are going to invalidate that no matter what some C committee somewhere says.
The issue is not developers, but disallowing the patterns is[a-z].*, to[a-z].*, str[a-z].* and others. Why would anyone do this to a programming language?
It's a stupid decision to reserve those and it ruins the usability of the language by arbitrarily disallowing many common words that have nothing to do with the intended feature. Even if you don't export names like this directly, having the name of your library or company (as prefix for all exported names) start with those common combinations is likely as well, so now you got to avoid certain library or company names.
If this is only since C11, then I'm even more baffled, since I could somewhat see how such thing could happen in the 1970s when there were limits and the language was brand new and not known to be popular, but in 2011 doing this makes no sense whatsoever.
I hope this is limited to C11 and will never happen in C++.
C doesn't even need namespaces for this, a simple stdc_ prefix for stdlib functions and types would also work (see C23 stdbit.h, I hope this won't be an outlier).
Yes, but we can't simply port C++ namespaces over because this requires symbol name mangling. C could be using 'namespace prefixes' instead with something like 'usingprefix stdc_', this wouldn't require changes to the symbol format, and would provide most of the features of C++ namespaces.
What else should they reserve in order to be able to introduce new identifiers? The alternative would be that new functions would have to look like __std_c__strfoo().
-use more obscure letter combinations than "is", "to" and "str" which are very common beginnings of words. How do "is", "to" and "str" help anyway if they want to add functionality that has no sensible name starting with those?
-use two underscores at the beginning since as per the article that is already reserved
Or introduce them as __newfunction for the linker, but have a new optional header file that #defines the short name. That’s the route that was chosen for C99’s _Bool/bool (there it was a typedef), and it worked well AFAIK.
The drawback of the macro solution is that it also disables those names for static symbols and struct members etc. when the header is included. For bool this was okay as it was intended as an opt-in keyword and the header was a new one, but doing that for all functions and in existing headers would potentially break more code.
TBH it would make a lot more sense if the C committee would start adding prefixes for new additions to the C stdlib (like the functions in C23 stdbit.h: stdc_popcount, stdc_bit_width, etc...)
> It's more like "disregard them at your own risk"
I'd argue that a compiler update that breaks existing code for something as innocuous as using the "wrong" variable name is a compiler bug, even if the code technically violates the spec. It is simply too late now for the spec to begin using the keywords they reserved 40 years ago.
In truth they've been careful about introducing names and not breaking existing code. For example, when they finally did a bool type, they called it _Bool to prevent incompatibilities with nonstandard bool types. You needed to include <stdbool.h> to get a friendly, usable name of "bool".
Within reason, yeah. Like if they chose to add a new "island" function and my geographics software broke, that's clearly the spec's fault, not mine, even though technically I'm violating spec. I'd even argue any "is.*" function is probably too late to add to the spec at this point in time.
> I'd even argue any "is.*" function is probably too late to add to the spec at this point in time.
I'd like to see isualpha() isudigit() isupunct() isuspace() isugraph() etc. plus isucombining(). They'd supplement iswxxx() but (a) taking a `signed unicode int` (for C2x defined as at least 32 bits wide) and (b) being locale-independent.
