-
Notifications
You must be signed in to change notification settings - Fork 11
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
POSIX: check if strtod() can handle hex #319
Conversation
I'm not certain we want this solution; it doesn't help with clang. See #320 for discussion. |
Hex support for strtod() was added to the C standard in C99. On Solaris, the documented default behaviour is not to support it [1]. (That said, `cc` and `c99` on Solaris 11.4.0.15.0 have no problem with it?) This commit allows gcc on Solaris to recognize that it needs to use -std=c99. [1] $ man 3 strtod In default mode for strtod(), only decimal, INF/INFINITY, and NAN/NAN(n-char-sequence) forms are recognized. In C99/SUSv3 mode, hexadecimal strings are also recognized. https://docs.oracle.com/cd/E88353_01/html/E37843/strtod-3c.html
2c48ff1
to
290d0ea
Compare
I don't like this:
|
Hmm. There's two sorts of run-time problems:
In the case of 1, I think that it would be nice to continue to detect & use the workarounds. I'd be happy to move that code to Alternatively, we could add a
and if there's an error of type 2, the message could just be
Asking for somebody to set a compiler flag manually would be a bit weird, but it would satisfy the concern about cross-compiling? Maybe? (Note that this would apply to The status quo which I want to avoid is this: the libcperciva tests fail on solaris + gcc, we don't change anything in kivaloo, we forget about this, then two years from now we get a confused bug report about kivaloo failing in a weird way, and after a few hours of debugging we figure out that Also, remember that there's a number of other functions whose behaviour differs between ANSI-C and C99. As far as I know, the only one that we use is |
I'm ok with the existing OS X hack. It's ugly but it's necessary for a widely used platform. (Hopefully at some point we can remove it though? I don't know how common that version is these days.) For the case of "Solaris and clang 6 a broken combination", I would probably just document in BUILDING. |
What about "solaris and gcc", which is a broken-but-fixable combination? Likewise just document it in BUILDING? |
I'd be inclined to just document that. I mean, the official way of building is |
That works for our POSIX Makefiles, but do you feel like taking a wild guess as to which compiler is the first choice of GNU autotools? :( I see three possibilities to allow tarsnap and scrypt to compile safely with a simple
Of course, there's also:
|
No description provided.