[musl] [PATCH] guard isascii() macro when using C++

[musl] [PATCH] guard isascii() macro when using C++

[Érico Nogueira]

From: Érico Rolim <ericonr@disroot.org>

otherwise one can get compilation errors in C++ code that uses isascii
as an identifier

this was spotted while building fceux
---
 include/ctype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/ctype.h b/include/ctype.h
index 7936536f..32bcef4d 100644
--- a/include/ctype.h
+++ b/include/ctype.h
@@ -64,7 +64,9 @@ int   isascii(int);
 int   toascii(int);
 #define _tolower(a) ((a)|0x20)
 #define _toupper(a) ((a)&0x5f)
+#ifndef __cplusplus
 #define isascii(a) (0 ? isascii(a) : (unsigned)(a) < 128)
+#endif
 
 #endif
 
-- 
2.29.2

Re: [musl] [PATCH] guard isascii() macro when using C++

[Markus Wichmann]

On Mon, Jan 04, 2021 at 10:48:34PM -0300, Érico Nogueira wrote:
> From: Érico Rolim <ericonr@disroot.org>
>
> otherwise one can get compilation errors in C++ code that uses isascii
> as an identifier
>

Well, this is a namespacing issue. The identifier in contention here is
only exposed if defines are set identifying the source file as POSIX
code. POSIX specifies the isascii macro, though it marks it as obsolete.
However, it means that no-one, C or C++, can use isascii as identifier
when including ctype.h if they declare POSIX compatibility. So one of
those three things has to go: Either the source files in question must
avoid including ctype.h, or they must avoid using the isascii
identifier, or they must avoid declaring POSIX compatibility. In all
cases, this is not a C vs. C++ issue, only a namespacing issue. And not
wrong in the library, but in the application.

Ciao,
Markus