You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently assume that C defines typedef int64_t long and typedef uint64_t unsigned long. This is not true on all platforms; for instance, Apple M1 and my NRF52 board (maybe this is an Arm-specific thing?).
Most of the generated code should be fairly robust to this, since we use our own i64 and u64 definitions. But two places where we rely on long == u64 are:
The formatter, which uses %ld and %lu.
Literals, which use 42L.
At the very least, this throws warnings. At worst, this causes unexpected behavior. We should modify the Backend compilation pass to be parametrized by some idea of what size the platform thinks long is, or better yet, make Backend agnostic of this issue and push the matter into C.
The text was updated successfully, but these errors were encountered:
We currently assume that C defines
typedef int64_t longandtypedef uint64_t unsigned long. This is not true on all platforms; for instance, Apple M1 and my NRF52 board (maybe this is an Arm-specific thing?).Most of the generated code should be fairly robust to this, since we use our own
i64andu64definitions. But two places where we rely onlong == u64are:%ldand%lu.42L.At the very least, this throws warnings. At worst, this causes unexpected behavior. We should modify the Backend compilation pass to be parametrized by some idea of what size the platform thinks
longis, or better yet, makeBackendagnostic of this issue and push the matter into C.The text was updated successfully, but these errors were encountered: