4 ms·
Strong evidence that these rules don't actually matter and can be disregarded.
by coldpie 4y ago
Strong evidence that these rules don't actually matter and can be disregarded.
- rwmj 4y agoFor sure! I've been writing C for about 40 years and didn't know that such innocent identifiers as "total" were reserved.
- raverbashing 4y agoIt's more like "disregard them at your own risk" The issue here is not GCC/Clang. It's developers You risk having a name collision if you define a strfoom in your code and then later the C committee decides to add that to string.h
- Aardwolf 4y agoThe 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++.
- zokier 4y agoRoot problem is the lack of namespaces in C, making collisions inevitable and painful to deal with
- flohofwoe 4y agoC 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).
- im3w1l 4y agoWith proper namespaces you can import stuff so you don't have to prefix with the namespace every time.
- flohofwoe 4y agoYes, 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.
- int_19h 4y agoThat gets very ugly very quick for something as basic as e.g. memcpy or strcmp.
- kevin_thibedeau 4y agoC23 technically has to support namespaces for attributes. It'll be interesting to see if they get adopted into the core language at some point.
- layer8 4y agoWhat 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().
- Aardwolf 4y agoThey could: -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 -use stdc_ as prefix
- codeflo 4y agoOr 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.
- layer8 4y agoThe 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.
- pmontra 4y agoI really hate leading underscores, in every language. stc_ or similar prefixes is the way to go.
- int_19h 4y agoStuff like "isalpha", "tolower", and "strlen" long predates standardization of C, so they had to work with what they already had.
- flohofwoe 4y agoTBH 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...)
- coldpie 4y ago> 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.
- Denvercoder9 4y agoFollowing that reasoning, the C standard library would _never_ be able to add another function (or macro, or struct, or...).
- coldpie 4y agoWithin 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.
- torstenvl 4y ago> 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.
- asveikau 4y agoIn 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". There was a similar thing for _Complex.
- jerf 4y agoI 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.