Thanks, Zachary.
Maybe that's where I'm getting confused. What is the case that it's testing?
It appears to simply be setting the locale such that the characters in
Invalid fail to be encoded correctly, then asserts that (a) the call to
VASPrintf() fails and (b) the resulting string is the expect
I believe locale codes are platform specific, so perhaps this ".932" is not
present on these systems. This was always a risk, but there's no other
good way to test this. Given that it's testing a very obscure error case,
one option would be to remove the test. Another would be to find out a
corr
Hi Zachary, Pavel,
I'm working on integrating the VASprintfTest.cpp test and other unittests
into the Xcode project and I wonder if I can get some information about
the EncodingError test in LLDB's VASprintfTest.cpp.
It seems to try to store the current locale; set the locale to a new,
invalid lo
Sorry about that, it's often frustrating to check every single buildbot
that was failing because 99% of the time they fail for exactly the same
reason, and when one is fixed all of them get fixed. In this case i used
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/5417 as
eviden
Hey Zach,
after you think you've fixed the build, could you check back on the
buildbot to make sure that it actually fixes things? In this case you
would've seen that after the build is fixed, the next thing it runs
into is about a dozen test failures.
In fact, this breakage was something that wo
