https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82316
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jordi Vilar from comment #4)
> I don't claim that a extern "C" declarations have to be interpreted as C in
> a C++ translation unit. What I say is that most C libraries (libtiff, zlib,
> lcms, etc.) provide a header that assumes that the C api can be reused for
> C++ just by wrapping it with extern "C" {}. If a C library uses register in
> its api declarations, then that legitimate C declarations no longer can be
> used in C++ code not even wrapped by extern "C". This is a breaking movement.
Yes.
> Supressing the warning in extern "C" declarations doesn't imply parsing it
> as C, because it is actually a C++ translation, but would enable continuing
> using the traditional C libraries.
But the warning is valid: it tells you that the C library is not compatible
with C++17.
> For an example of C library that uses register in its api, you can take a
> look on the little cms (lcms) that is included in most linux distributions.
> It just has the classic #ifdef __cplusplus extern "C" { #endif and tons of
> register function arguments.
That library is silly: the register keyword is almost useless and the compiler
almost always does a better job of deciding what to put in registers. It's not
1970.
> Should C++17 applications REJECT all of those ligitimate C libraries?
It's not valid C++17 code, so yes. It's only a warning though, so you can
ignore it, or suppress it with -Wno-register.
If the libraries want to be valid for use in C++ then they should not use
'register' when parsed as C++, because it's not valid e.g.
#ifdef __cplusplus
extern "C" {
#define register
#endif
...
#ifdef __cplusplus
}
#undef register
#endif
The warning is valid and helps find code that needs to be fixed for C++
compatibility.
