On 01/07/2020 16:02, Raphael Isemann via lldb-commits wrote: > > Author: Raphael Isemann > Date: 2020-07-01T16:00:10+02:00 > New Revision: f3b5bf3eb7029238cead637be2e285b443b2e141 > > URL: > https://github.com/llvm/llvm-project/commit/f3b5bf3eb7029238cead637be2e285b443b2e141 > DIFF: > https://github.com/llvm/llvm-project/commit/f3b5bf3eb7029238cead637be2e285b443b2e141.diff > > LOG: [lldb] Fix NSDate test after Scalar change > > The formatter was requesting an unsigned integer from the ValueObject, > but CFAbsoluteTime is a signed double, so in the NSDate test the formatter > actually just printed the 'error value' date which is the Cocoa epoch. This > started failing after the recent Scalar changes. > > This patch just changes the logic to use a signed value which fits to the data > we try to read and avoids this issue. >
For the record, the thing that changed was that the new implementation of Scalar::ULongLong clamped out-of-range values to min/max. For unsigned types, anything negative gets clamped to zero. It did that because that's what the underlying llvm api does, and it seems like the most reasonable option (C considers these conversion undefined behavior). If I am reading correctly, the previous API folded out-of-range values to zero, but it always considered the resulting APInt to be signed. So the negative values used here were in range, and the subsequent cast to unsigned long long and then to time_t preserved the value, mostly by accident. TL;DR: GetValueAsSigned is definitely a better way to retrieve these values. _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
