It is weird, I think everyone hates it. One day I'll try to change it, but
since it's used so widely, it's a risky change.
If it helps, you can think of the return value as a std::error_code, where
the operator bool returns true if there's an error. Like
if (std::error_code EC = foo())
handleErro
base of 16 was only used in a few places. It's used frequently in the gdb
remote protocol code, but I don't think the gdb remote protocol ever sends hex
numbers with the 0x prefix, it assumes you know the radix, so that should be
okay. Other than that this was the only consequential usage. So
It does seem unfortunate that getAsInteger works differently from strtol's
documented behavior in this little way... Makes conversions like this one
trickier than necessary. But presumably somebody had a reason for it to be
different?
Anyway, I have to go see if this feature of strtol & Co. i
What if you write this:
// Explicitly try hex. This will catch the case where there is no 0x
prefix.
if (entry.ref.getAsInteger(16, uval64)) {
// If that fails, let the algorithm auto-detect the radix. This will
catch the case where there is a 0x prefix.
if (entry.ref.getAsInteger(0, uval64)
>
I think somebody was being too clever. The real purpose for specifying the
format is to set the byte size of the item written down:
OptionValueUInt64 &byte_size_value = m_format_options.GetByteSizeValue();
size_t item_byte_size = byte_size_value.GetCurrentValue();
and to do some spe
That does seem unintentional. Is there any particular reason we want to
hint the radix? If you're going to specify 0x anyway, then what value does
adding the 16 to the getAsInteger add?
On Wed, Apr 5, 2017 at 3:37 PM Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> memory write's ar
memory write's argument ingestion was changed as part of the StringRefifying of
Args so that we get:
(lldb) memory write &buffer 0x62
error: '0x62' is not a valid hex string value.
That seems unexpected and not desirable. What's going on is that the default
format is hex, and if the format is
No prob, I scanned those changes and should have noticed the omission at the
time...
Jim
> On Apr 5, 2017, at 1:50 PM, Pavel Labath wrote:
>
> That looks like one of my changes. While refactoring the channels (I am done
> with that now btw), I deleted some unused categories, mostly in the "po
That looks like one of my changes. While refactoring the channels (I am
done with that now btw), I deleted some unused categories, mostly in the
"posix" channel, but this I deleted this one as well.. I didn't call that
out explicitly during review, as it seemed easy to add back those that turn
out
