Open arsdragonfly opened 5 years ago
Currently the gcc preprocessor output varies depending on the language set. On my system, this is what a short c program's output looks like:
⚡ gcc -E test.c # 1 "test.c" # 1 "<built-in>" # 1 "<命令行>" # 31 "<命令行>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "<命令行>" 2 # 1 "test.c" int main() { return 0; }
and c2hs can't process it due to not being able to handle non-ascii characters in line 3, 4 and 6. See #237 .
if we override the environment variable LANG, we get
⚡ LANG=ASCII gcc -E test.c # 1 "test.c" # 1 "<built-in>" # 1 "<command-line>" # 31 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "<command-line>" 2 # 1 "test.c" int main() { return 0; }
which works correctly.
This bug is breaking every test case and causing more problems downstream (every package that depends on c2hs is failing to build right now). I suppose it has something to do with takeChar's implementation.
Prelude.head: empty list error appears on international locales; needs export LANG=C as workaround.
Prelude.head: empty list
export LANG=C
Currently the gcc preprocessor output varies depending on the language set. On my system, this is what a short c program's output looks like:
and c2hs can't process it due to not being able to handle non-ascii characters in line 3, 4 and 6. See #237 .
if we override the environment variable LANG, we get
which works correctly.
This bug is breaking every test case and causing more problems downstream (every package that depends on c2hs is failing to build right now). I suppose it has something to do with takeChar's implementation.