-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
BUG: on Apple platforms changed long long format from "%Ld" to "%lld" #90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
/* #define LONGLONG_FMT "lld" Another possible variant | ||
#define ULONGLONG_FMT "llu" | ||
|
||
# elif defined __APPLE__ /* "%Ld" only parses 4 bytes on 32-bit MacOS X */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't use trailing comments, put it on the next line. Apropos trailing comments in general, I think they should be used sparingly, mostly for things like structure members, etc.
Actually on Linux "L" also is only documented as length modifier for floating point types - can anyone comment on what platforms would not support "%lld"? |
Apparently the "ll" formats were broken on FreeBSD at some point in the last millennium, thus the occasional use of the "q" alternatives. Both still work on OS X as well. |
From MSDN, it looks like Visual Studio introduced the 'll' format support in the 2005 version. |
I've merged the pull request. |
feat: Add vabal_s8
Resolves a test failure on PPC with Mark's recent datetime updates, but should fix print formats on 32bit MacOS X in general, where "%Ld" would only use 4 bytes at a time. For an npy_int64 year=1970 this print
"%Ld - %Ld", year, year
produced "0 - 1970" on ppc and "1970 - 0" on i386, while "%lld - %lld" prints "1970 - 1970" on both archs.
"That proves that it's wrong on i386 as well, and it makes perfect sense for big endian and little endian architectures." (-Mark)