reserved identifier violation

[elfring]

I would like to point out that identifiers like “__math_compat_h” and “__STRING” do eventually not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

[hawicz]

Meh, if it's causing an actual problem then of course let's change it, but otherwise it seems like needless work. However, if you want to submit a pull request, go ahead and I'll merge it.

[elfring]

How do you think about to avoid that this software depends on undefined behaviour?

[hawicz]

What are you talking about? If you are seeing an actual concrete problem, then please explain. If you have some change that you're proposing, please submit a pull request.

[elfring]

Would you like to achieve standard compliance also for this software library?

[hawicz]

Blind adherence to some standard, without consideration for the practical impacts would be a waste of time for me, but if you want to submit a PR to change the header guards even, then be my guest.

[hawicz]

Also note that json-c is a C library, not a C++ one, so it's even less useful to try to apply C++ guidelines to its header files, especially those meant only for internal use.

[elfring]

Should this software library be safely usable not only for implementations of compilers for these programming languages?

[ploxiln]

That page has both "critical undefined behavior" and "bounded undefined behavior". When people talk about undefined behavior in C, they talk about the "critical" kind. But some conflict over identifiers is the "bounded" kind which just means that some future compiler+libc may theoretically fail to compile json-c due to an identifier name conflict. At that time we will notice.

I suggest not trying to dig up and find theoretical problems about which you simply do not understand. It's ok, you don't have to understand it all in order to be a decent programmer, it takes a lot of time and experience, this is cryptic archaic systems stuff ...

[elfring]

How does the probability look like to notice anything (besides the application of strict static source code analysis) when undefined behaviour could be involved because other programmers are using this software library not only for compiler implementations?

[hawicz]

Who said anything about using this within compiler implementations? I certainly did not.

IMO, the probability of noticing a problem in this specific concrete case of header guards is quite high, as either you'll be missing definitions from a system header and the code won't compile, or you'll be missing definitions from the json-c header, and again the code won't compile.
If it happens to compile anyway, the chance that the behavior of the defined symbols is different than expected is nearly zero (isnan, isinf, etc... will be pretty consistent), and even if it is different then the automated tests will catch the discrepancies.

"undefined behavior" doesn't mean it's some sneaky, impossible to notice case. It just means that the behavior isn't defined by the standard that you happen to be reading, so to determine what actually happens you need to look beyond the standard.