================
@@ -1089,6 +1089,116 @@ int64_t ValueObject::GetValueAsSigned(int64_t
fail_value, bool *success) {
return fail_value;
}
+llvm::APSInt ValueObject::GetValueAsAPSInt() {
+ lldb::TargetSP target = GetTargetSP();
+ uint64_t byte_size = 0;
+ if (auto temp = GetCompilerType().GetByteSize(target.get()))
+ byte_size = temp.value();
+
+ unsigned bit_width = static_cast<unsigned>(byte_size * CHAR_BIT);
+ bool success = true;
+ uint64_t fail_value = 0;
+ uint64_t ret_val = GetValueAsUnsigned(fail_value, &success);
+ uint64_t new_value = fail_value;
+ if (success)
+ new_value = ret_val;
+ bool is_signed = GetCompilerType().IsSigned();
+
+ return llvm::APSInt(llvm::APInt(bit_width, new_value, is_signed),
!is_signed);
+}
+
+llvm::APFloat ValueObject::GetValueAsFloat() {
----------------
bulbazord wrote:
2 issues and a small nitpick:
Nit: The name could be `GetValueAsAPFloat` to differentiate between it and a
potential function that would return a `float`/`double`?
1. I don't think assertions are the right way to make sure we have good data.
`GetData` has error handling through its `Status &` out parameter, we should
handle that appropriately instead of asserting that we got good data. What
happens when we compile out the assertions for release builds? Reading data
from the `DataExtractor` will fail and crash regardless.
2. This function has no way of returning a value that would indicate failure.
Suggestion: Return `std::optional<llvm::APFloat>` or
`llvm::Expected<llvm::APFloat>`. There's no way to return an invalid `APFloat`
from looking at the header, so that doesn't appear to be an option. Then if any
of the steps fail, you can return either `std::nullopt` or an appropriate
`llvm::Error`.
https://github.com/llvm/llvm-project/pull/87197
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
