Closed jprjr closed 4 years ago
I won't have any more pushes to this PR. Like before, I verified that every commit produces the exact same binary as before, there's no functional changes, it's all changes for the preprocessor (and adding an itoa
replacement for Linux/unix)
What does "gcc/clang spacing on integer constants" mean? I'm unclear what this fixes.
I believe it has to do with how clang/gcc is parsing 0x400e-0x4008
- specifically because it ends with an e, the error doesn't show up on the other values that are strictly numeric, I added the spacing to the other values just so they're all uniform.
Example - here's a small C++ program:
#include <stdio.h>
int reg[0x100];
int main(void) {
int i;
for(i=0;i<0x100;i++) reg[i] = i;
i = reg[0x400e-0x4008]; /* should return 6 */
printf("r=%d\n",i);
return 0;
}
And when I try to compile with clang:
clang++ demo.cpp
demo.cpp:8:19: error: invalid suffix '-0x4008' on integer constant
i = reg[0x400e-0x4008]; /* should return 6 */
^
1 error generated.
g++ gives a slightly better error message:
g++ demo.cpp
demo.cpp: In function 'int main()':
demo.cpp:8:13: error: unable to find numeric literal operator 'operator""-0x4008'
8 | i = reg[0x400e-0x4008]; /* should return 6 */
|
When I add a space around the minus sign, it realizes it's meant to be a subtraction.
Oh and just for completeness sake - when I add spaces around the minus sign:
#include <stdio.h>
int reg[0x100];
int main(void) {
int i;
for(i=0;i<0x100;i++) reg[i] = i;
i = reg[0x400e - 0x4008]; /* should return 6 */
printf("r=%d\n",i);
return 0;
}
clang++ demo.cpp
./a.out
r=6
Thanks for the explanation. That's an extremely curious way to parse a hexadecimal value... surprised I've never encountered it before. I guess I need to be careful when ending one with E. :(
These fix a few minor errors reported by gcc/clang.
I used ducible to verify that binaries produced by Visual Studio are identical to the master branch.