Package: elm-compiler Version: 0.19.1-2 Severity: important Tags: upstream Dear Maintainer,
On some platforms, 0xFFFFFFFF does not parse in elm. This is likely due to the number parser using Haskell's Int type to represent numbers [1], which is only guaranteed to be at least 30 bits. On a 32-bit platform, Int is a signed 32-bit integer, so cannot hold 0xFFFFFFFF as a positive integer. Oddly, replacing 0xFFFFFFFF with its decimal equivalent does actually parse correctly. This alone wouldn't be so bad, however the main problem is that there is an instance of this in every version of the core library, in src/Array.elm, line 102 [2]. In any case, libraries are normally downloaded on demand, so a fix would need to be in the aforementioned parser anyway. A workaround is to let the first compilation with elm fail, then patch the downloaded library (in ~/.elm/0.19.1/packages/elm/core/1.0.*/src/Array.elm) by replacing 0xFFFFFFFF with 4294967295 and all subsequent compilations should then succeed. [1] https://sources.debian.org/src/elm-compiler/0.19.1-2/compiler/src/Parse/Number.hs/ [2] https://sources.debian.org/src/elm-compiler/0.19.1-2/packages/elm/core/1.0.2/src/Array.elm/#L102 Regards, Pete -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 5.15.74-v7l+ (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages elm-compiler depends on: ii libc6 2.35-4 ii libffi8 3.4.4-1 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libtinfo6 6.3+20220423-2 ii zlib1g 1:1.2.11.dfsg-4.1 elm-compiler recommends no packages. elm-compiler suggests no packages. -- no debconf information
