Fixes: Can not use C99 function names as variable names in C89

[vinay-deshmukh]

Fixes #15522

Essentially all of math.h doesn't exist until C99: https://en.cppreference.com/w/c/numeric/math/log

Todo: need more granular filtering based on poring the reference

[frederick-vs-ja]

Essentially all of math.h doesn't exist until C99: https://en.cppreference.com/w/c/numeric/math/log

You seemed to misread the page. logf and logl exist since C99, while log exists since C89.

[vinay-deshmukh]

Essentially all of math.h doesn't exist until C99: https://en.cppreference.com/w/c/numeric/math/log

You seemed to misread the page. logf and logl exist since C99, while log exists since C89.

@frederick-vs-ja

My bad, I should have better clarified my previous comment.

While log does exist since C89 within <math.h>, it should be allowed for a .c to define int log = 0; because the math.h has not been included. Thereby, even if double log(double); exists in C89 (in math.h), it's not been declared in the current translation unit, so declaring a symbol with the same name as log seems to be valid IMO.

GCC's behavior seems to be that even if builtins are "re-defined" it is allowed, when there is no explicit include for math.h

Reference:

I've made a godbolt link https://godbolt.org/z/zY76dWa84 with all the symbols on https://en.cppreference.com/w/c/numeric/math

All panels have -std=c89 in common and are the respective trunk versions.

1. Panel 1: GCC builds with warnings [-Wbuiltin-declaration-mismatch]
2. Panel 2: Clang builds (after passing non-default options, this PR will make those effective when using -std=c89) and no warnings despite -Wall
3. Panel 3: Clang fails to build (this issue)

[frederick-vs-ja]

While log does exist since C89 within <math.h>, it should be allowed for a .c to define int log = 0; because the math.h has not been included. Thereby, even if double log(double); exists in C89 (in math.h), it's not been declared in the current translation unit, so declaring a symbol with the same name as log seems to be valid IMO.

However, declaration it as an object with external linkage is UB (or ill-formed, no diagnostic required in the C++ standard wording).

Per N3220 7.1.3/1

[...]
— All identifiers with external linkage in any of the following subclauses (including the future library directions) and errno are always reserved for use as identifiers with external linkage.²¹⁸⁾
[...]

In C89 that was in 4.1.2

[...] All external identifiers declared in any of the headers are reserved, whether or not the associated header is included. [...]

It seem to me that the following program was well-defined in C89 but became undefined (IFNDR) since C99.

int logf = 0; /* N.B. static not used */
int main(void) { return logf; }

But if logf is replaced with log, the program is invalid even in C89.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[vinay-deshmukh]

I'm a bit confused about the whole what is not UB/IFNDR in C89, but is in C99. Based on my current understanding the simplest way to resolve the issue seems to what I've done as of:
7572c21

Is not define builtins for symbols available in C89?

let me know if that looks good.

[vinay-deshmukh]

@frederick-vs-ja

Any suggestions on how to go about making further progress on this one? Sort of stuck right now.

[vinay-deshmukh]

@frederick-vs-ja

Any suggestions on how to go about making further progress on this one? Sort of stuck right now.

@frederick-vs-ja bump

[frederick-vs-ja]

The list would be very long, see https://port70.net/~nsz/c/c89/c89-draft.html. Perhaps we should add a .def file for this.