[Bug]: NDK header patches use non reserved identifiers in local variables

[ngtv2409]

Problem description

Title. Here is an example:

https://github.com/termux/termux-packages/blob/master/ndk-patches/23c/stdio.h.patch

int open(const char*, int, ...);
extern pid_t getpid();
extern int unlink(const char*);
void free(void* p);
uint32_t arc4random(void);
static __inline__ FILE* tmpfile() {
	int p = getpid();
	char* path;
	int i;
	for (i = 0; i < 100; i++) {
		unsigned int r = arc4random();
		if (asprintf(&path, "@TERMUX_PREFIX@/tmp/tmpfile.%d-%u", p, r) == -1) return NULL;
		int fd = open(path, O_RDWR | O_CREAT | O_EXCL | O_LARGEFILE, 0600);
		if (fd >= 0) {
			FILE* result = fdopen(fd, "w+");
			unlink(path);
		free(path);
			return result;
		}
		free(path);
	}
	return NULL;
}

r, p, result, ... are unreserved identifiers.

This is a problem if there is a macro definition clashing with these identifiers. Although unlikely for any real codebases.

What steps will reproduce the bug?

Source code.

What is the expected behavior?

According to the C23 standard:

7.1.3 reserves certain names and patterns of names that an implementation can use in headers. All other names are not reserved, and a conforming implementation is not permitted to use them

https://cigix.me/c23#footnote456

System information

Unrelated.

[robertkirkman]

Although unlikely for any real codebases.

I already know about this and have a real world example:

• #define p 761 conflicts with Termux variant of Android NDK, preventing build for Termux open-quantum-safe/liboqs#2324

In the real world example, I observed the developers of the upstream library software become disconcerted about the state of the code involved on their end, and watched them solve the problem by deleting and abandoning the code that contained the conflicting unreserved identifier. While that way of working around this problem is not the standards-conformant one (which would be Termux making a change for that), it demonstrates an example that application code constructed in a way that can reproduce this problem in the real world might be likely to be considered ugly by its authors to an equal or greater degree than they consider Termux's headers, meaning that real-world manifestations of this bug might tend to look like an accidental competition between Termux and the software with which it conflicts about which has uglier code.

In an ideal world I agree that Termux should conform to the standard so that compatibility with even the ugliest application code is guaranteed at least in this aspect.