8 ms·
clang recently added `-Wreserved-identifier`, I think in v14 or v15. I may be slightly off in how it is said, but it’s there. Not sure about gcc
by beached_whale 4y ago
clang recently added `-Wreserved-identifier`, I think in v14 or v15. I may be slightly off in how it is said, but it’s there. Not sure about gcc
- rwmj 4y agoThe GCC bug's only been around for 11 years: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
- coldpie 4y agoStrong 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().
- 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.
- kps 4y agoAlso, clang-tidy has `bugprone-reserved-identifier` https://clang.llvm.org/extra/clang-tidy/checks/bugprone/reserved-identifier.html https://clang.llvm.org/extra/clang-tidy/checks/bugprone/rese...
- planede 4y agoIt only checks for the ones starting with underscore. > This check does not (yet) check for other reserved names, e.g. macro names identical to language keywords, and names specifically reserved by language standards, e.g. C++ ‘zombie names’ and C future library directions.
- peterfirefly 4y agoAnd it complains about this: #define _POSIX_SOURCE which is sometimes needed before the #include's to get access to nice, modern library functions that are, say, thread-safe.