Closed mscdex closed 2 years ago
It looks like the character "R" is some kind of reserved token that I'm blanking on at the moment. Changing the macro variables to start with "A" instead of "P" in all of the macro functions fixes things.
Ah ok it seems that "R" is a valid string literal prefix much like "L" can be for wide strings. Apparently there are others that I was unaware of like "U"/"u" and "u8" according to here.
I think this might be a side effect of compiling this C library as C++ code. We're being hit by a language incompatibility.
In the C world, this would be gross behavior by GCC, because the R
variable is only supposed to be seen by the preprocessor. And the preprocessor is only supposed to do textual substitution. The R
is never supposed to be visible to the compiler, at all, ever. So through that lens, this bug makes no sense and seems bizarre.
In C++ it's apparently acceptable?
Anyway, thanks for finding this bug/incompatibility. I think your PR is the right fix.
It looks like at least gcc fails now with
BASE64_NEON64_USE_ASM
set and-O0
. Example output:and a bunch of similar "stray 'R'" errors after that.
clang compiles without errors however.