6 ms·

"It may come as a surprise that the C language reserves identifiers like strong, island, and together, but it does." Yes, I would guess that a large proportion

by bloak 4y ago

"It may come as a surprise that the C language reserves identifiers like strong, island, and together, but it does." Yes, I would guess that a large proportion of C programmers are not familiar with those rules. Is there a way of getting GCC or LLVM to warn about it?

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 ago
  The 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 ago
    Strong evidence that these rules don't actually matter and can be disregarded.
    - rwmj 4y ago
      For sure! I've been writing C for about 40 years and didn't know that such innocent identifiers as "total" were reserved.
    - raverbashing 4y ago
      It'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 ago
        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++.
        zokier 4y ago
        Root problem is the lack of namespaces in C, making collisions inevitable and painful to deal with
        flohofwoe 4y ago
        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).
        im3w1l 4y ago
        With proper namespaces you can import stuff so you don't have to prefix with the namespace every time.
        flohofwoe 4y ago
        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.
    - jerf 4y ago
      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.
- kps 4y ago
  Also, 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 ago
    It 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 ago
  And 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.
marssaxman 4y ago
After thirty-some-odd years writing C, this is the first I have ever heard of it. I wonder how many times I have inadvertently broken those rules.
deleted 4y ago
[deleted]

by bloak 4y ago

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 ago
The 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 ago
  Strong evidence that these rules don't actually matter and can be disregarded.
  - rwmj 4y ago
    For sure! I've been writing C for about 40 years and didn't know that such innocent identifiers as "total" were reserved.
  - raverbashing 4y ago
    It'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 ago
      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++.
      - zokier 4y ago
        Root problem is the lack of namespaces in C, making collisions inevitable and painful to deal with
        flohofwoe 4y ago
        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).
        im3w1l 4y ago
        With proper namespaces you can import stuff so you don't have to prefix with the namespace every time.
        flohofwoe 4y ago
        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.
  - jerf 4y ago
    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.
kps 4y ago
Also, 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 ago
  It 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 ago
And 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.

marssaxman 4y ago

After thirty-some-odd years writing C, this is the first I have ever heard of it. I wonder how many times I have inadvertently broken those rules.

deleted 4y ago

[deleted]