Single-line C++ comments causes problem at projects with a strict ANSI C (C89/C90)

[Wohlstand]

Is your feature request related to a problem? Please describe. Using C++ comments in public headers causes compilation errors in projects that enforce the C98/C90 standard or use the C99-incompatible compiler. These comments are allowed since C99, but they shouldn't be used in public headers at all. It's fine to use single-line comments at private headers/sources within the scope of the single project, but, it's totally not recommended to use single-line comments at Pure-C sources/headers intended to be included with other projects.

Describe the solution you'd like Any single-line comments // <something> should be replaced with multi-line comments /* something */ to avoid compile problems on strict ANSI-C projects.

[nothings]

stb has been using // comments since its inception in 2005 and I don't think that's going to change.

[N-R-K]

The main issue here is the fact that gcc will error out on c++ style comments when using -std=c89. clang let's you go with a warning, tcc doesn't care, don't know about msvc.

$ cat test.c
int main(void) { return 0; } //test
$ gcc -std=c89 -Wpedantic -o test test.c
test.c:1:30: error: C++ style comments are not allowed in ISO C90
    1 | int main(void) { return 0; } //test
      |                              ^
test.c:1:30: note: (this will be reported only once per input file)
$ clang -std=c89 -Wpedantic -o test test.c
test.c:1:30: warning: // comments are not allowed in this language [-Wcomment]
int main(void) { return 0; } //test
                             ^
1 warning generated.
$ tcc -std=c89 -Wpedantic -o test test.c
$

I'm not entirely sure why gcc errors out completely, but AFAIK there's some edge cases where c++ style comments can silently change the semantics of a C89 source code, so that could be the reason.

[nothings]

AFAIK, gcc errors out completely because it's against the spec, not because it could actually cause any problems.

[Wohlstand]

I noted that this problem is for strict ANSI C projects with enforced standard usage: if public headers have C++ comments, the build gets killed. These projects were targeted to be built on a wide amount of compilers, and having standards enforced, allows to verify the build and ensure it will build on any other compiler than modern GCC and CLang.

[nothings]

yes, you already noted that, you don't have to repeat yourself.

do these projects exist or is this purely hypothetical?

[Wohlstand]

One of my projects (MixerX - fork of SDL Mixer) exactly uses this, and some of my library projects also use the standard enforcement use, because they are targeted to be built on a wide range of compilers including very old (such as Wattcom family). In other cases, C++ comments cause warnings being popped up if C99 or C11 wasn't specified explicitly in the project.

[N-R-K]

AFAIK, gcc errors out completely because it's against the spec, not because it could actually cause any problems.

Not to derail this issue, but off the top of my head, I remember something like the following which can cause problems:

n = 8 //* comment */ 2;

Which I think is valid (8 / 2) in C89 but would be error in C99 and later due to // comments. How much, if ever, this occurs in practice is another topic entirely.

[rygorous]

Closing this issue; all of the stb libraries have been using // comments since the very first releases and expanding support for pre-C99 compilers at this stage is an explicit non-goal. I don't think any of the libraries currently have // occurring in any strings meaning that the comments should be trivial to convert if required using regular expression search & replace or a sed one-liner.

Niche platforms and toolchains, especially old ones, already cause a disproportionate maintenance burden (relative to the user count) for us. You are welcome to adapt the stb libraries to such environments if you want, but that's going to be in a private fork. Accepting such patches in this repository would imply a level of support for such environments that we are both unable (due to lack of access) and unwilling (due to very limited time to spend on stb libs in general) to provide.