Thu 05 May 2016 06:12:27 PM UTC, comment #12:
Yes, it was only left open because the bug hasn't been fixed in llvm's libc++ yet, but you're right we don't have to leave bugs open to track external bugs. It might be nice to have a way to track them somewhere, so periodically we can see if they've been addressed yet.
|
Thu 05 May 2016 08:01:35 AM UTC, comment #11:
This has been "won't fix" for over a month.
Is it open to avoid others reporting the same bug? I'm (tentatively) closing it.
|
Tue 15 Mar 2016 05:25:26 PM UTC, comment #10:
Good demo. That turns out to be this open bug report against LLVM: https://llvm.org/bugs/show_bug.cgi?id=17782
My understanding of the standard is that Octave is doing the right thing and LLVM is not.
|
Tue 15 Mar 2016 02:02:47 PM UTC, comment #9:
The following program seems to be enough to demonstrate the problem. I think it should write "val: 1, failbit: 0" but it writes "val: 0, failbit: 4" when using clang++ 3.7 and libc++.
If you put a space between the '1' and the 'a' in the stringstream, it works. But I think it should stop reading the double value after the 1 either way. Am I wrong? If the clang+libc++ behavior is standard conforming, we probably have a lot of work to do to fix the way Octave reads numbers, so I hope I'm not wrong...
|
Tue 15 Mar 2016 02:02:02 PM UTC, comment #8:
The following program seems to be enough to demonstrate the problem. I think it should write "val: 1, failbit: 0" but it writes "val: 0, failbit: 4" when using clang++ 3.7 and libc++.
If you put a space between the '1' and the 'a' in the stringstream, it works. But I think it should stop reading the double value after the 1 either way. Am I wrong? If the clang+libc++ behavior is standard conforming, we probably have a lot of work to do to fix the way Octave reads numbers, so I hope I'm not wrong...
+verbatim-
#include <iostream>
#include <sstream>
int
main (void)
{
std::istringstream s1 ("1asdf");
double val = 0.0;
is >> val;
std::cerr << "val: " << val
<< ", failbit: " << (is.rdstate () & std::ios::failbit)
<< std::endl;
return 0;
}
-verbatim-
|
Tue 15 Mar 2016 01:30:07 PM UTC, comment #7:
I see the same results:
|
Tue 15 Mar 2016 04:43:04 AM UTC, comment #6:
Seems to be better now. I'll see if I can duplicate the problems tomorrow.
|
Tue 15 Mar 2016 04:38:32 AM UTC, comment #5:
Oops, I might have been out of date with libc++. I updated it and now I'm trying again.
|
Tue 15 Mar 2016 04:33:53 AM UTC, comment #4:
That looks like an error that was fixed in a previous version of libc++. Do you have libc++ 3.5? See bug #43298. I have libc++ 3.7 from Debian unstable installed and I don't have any build errors. I don't think Debian gives you the option of having more than one libc++ installed at the same time.
|
Tue 15 Mar 2016 04:22:08 AM UTC, comment #3:
On my Debian system, I used:
and I'm seeing a build error that begins with
|
Tue 15 Mar 2016 03:56:20 AM UTC, comment #2:
With GCC's libstdc++:
With LLVM's libc++:
The former does not show these errors, and the only difference is which STL headers and runtime library are used, so it's probably something in LLVM's implementation of the STL, maybe the iostream classes?
|
Tue 15 Mar 2016 03:50:27 AM UTC, comment #1:
What configure command line did you use to build with clang and libc++?
|
Tue 15 Mar 2016 02:19:26 AM UTC, original submission:
Building Octave with clang 3.7 and libc++ 3.7 results in some strange string to numeric conversion errors. There may be a single point of failure or a class of functions failing here, but I haven't tracked it down yet. Here are some examples of failures with clang's libc++ version 3.7:
|