[Lldb-commits] [lldb] f3b5bf3 - [lldb] Fix NSDate test after Scalar change

[Pavel Labath via lldb-commits]

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.