Thanks for the report. The problem appears to be with how glibc's nl_langinfo() is returning values on s390x (or, at least, with how ncal *assumes* it will return them). Here's a short test program:
---
int main() {
int i = (intptr_t)nl_langinfo(_NL_TIME_WEEK_1STDAY);
printf("1ST DAY IS %d\n", i);
}
---
On x86, this, for most locales, will output:
$ ./test
1ST DAY IS 19971130
However, on s390x, it outputs:
$ ./test
1ST DAY IS 0
However, if you look at the full pointer, you can see that s390x does have the correct value in the top order bytes:
Thanks for the report. The problem appears to be with how glibc's nl_langinfo() is returning values on s390x (or, at least, with how ncal *assumes* it will return them). Here's a short test program:
--- t)nl_langinfo( _NL_TIME_ WEEK_1STDAY) ;
int main() {
int i = (intptr_
printf("1ST DAY IS %d\n", i);
}
---
On x86, this, for most locales, will output:
$ ./test
1ST DAY IS 19971130
However, on s390x, it outputs:
$ ./test
1ST DAY IS 0
However, if you look at the full pointer, you can see that s390x does have the correct value in the top order bytes:
ubuntu@s390x:~$ cat test.c
#include <stdio.h>
#include <langinfo.h>
#include <stdint.h>
int main() { _NL_TIME_ WEEK_1STDAY) ;
char *p = nl_langinfo(
printf("1ST DAY IS %p\n", p);
}
ubuntu@s390x:~$ gcc test.c -o test
ubuntu@s390x:~$ ./test
1ST DAY IS 0x130bc3a00000000
While on x86/arm64 it is in the lower bytes:
ubuntu@x86$ ./test
1ST DAY IS 0x130bc3a