cImport / translate-c picks the wrong C type when parsing integer literals about zig HOT 2 OPEN

This fix adds c_ulonglong to the list of signed candidate types. This seems to be at odds with C std 6.4.4.1p5 which, for instance, requires the extension type to be signed for unsuffixed signed decimal constants, per the table note above.

clang and gcc differ here - GCC follows the standard and promotes to __int128; clang converts it to unsigned long long. Since translate-c is based on clang we follow the clang behavior: https://godbolt.org/z/W75c6WGjY

Currently aro follows the clang behavior but we should update it to be able to do either depending on what compiler is being emulated.

from zig.

clang and gcc differ here - GCC follows the standard and promotes to __int128; clang converts it to unsigned long long. Since translate-c is based on clang we follow the clang behavior: https://godbolt.org/z/W75c6WGjY

Currently aro follows the clang behavior but we should update it to be able to do either depending on what compiler is being emulated.

Thanks for the insights. IMO, Zig should definitely not perpetuate behavior like converting unsuffixed decimal constants to ULL. Moreover, it seems that translate-c doesn't promote to a larger type at all in parseCNumLit (though I'm not that familiar with the code base so could be missing something), while c_translate goes the non-compliant clang route in promoteIntLiteral.

from zig.