I think at least the c header file should be compatible with c++ compiler, but the c source file could use sme incompatible language features.
On Sat, Sep 16, 2023 at 8:47 AM Daniel Appiagyei <daniel.appiag...@braincorp.com.invalid> wrote: > Hi, > I'm following up on an issue > <https://github.com/apache/nuttx/issues/10556#issuecomment-1712717696> I > opened about a C header file not being compatible with a C++ compiler > because of it using reserved C++ keywords. I'm fixing this issue for header > files but wanted to know if we want to endorse C++ compatibility for our C > source files as well. > > GCC has the -Wc++-compat > < > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wc_002b_002b-compat > > > flag > which we could enable as an error instead of a warning. Here's an example > of it catching us using the reserved keyword 'or': > ``` > misc/lib_fnmatch.c:193:19: warning: identifier "or" is a special operator > name in C++ [-Wc++-compat] > ``` > Aside from reserved keywords being used, C++ doesn't support *implicit > *conversions > from void* to other types. The majority of nuttx code I've seen so far > *explicitly* casts anyway, so I don't see requiring explicit casts being a > major hurdle. Refactoring our codebase to be c++ compliant would therefore > mainly be find/replace for reserved keywords and adding explicit casts > (straightforward). I can do the work and it would only take a couple weeks. > > My questions are these: > *Does NuttX want to officially agree to and enforce that*: > 1. all C headers and source file be compatible with C++, or > 2. all C headers be compatible *and* only C++ source files with 'extern > "C"' in them be compatible > > Secondly, if we decide on one of the above rulings, do we want to add the > ruling to our C coding style guidelines > < > https://nuttx.apache.org/docs/latest/contributing/coding_style.html#general-conventions > > > ? > > Thanks, > Daniel > > > <bog...@braincorporation.com> >
