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.<br><br>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 <br><br>if (std::error_code EC = foo())<br> handleError();<br><br>Is pretty intuitive, it's just weird with bool.<br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 5, 2017 at 6:55 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 I went with detecting the 0x by hand and treating that separately (r299609).<br>
<br>
Why does getAsInteger return false if it succeeds in getting an integer? That just seems weird to me.<br>
<br>
Jim<br>
<br>
<br>
> On Apr 5, 2017, at 4:36 PM, Jim Ingham via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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?<br>
><br>
> Anyway, I have to go see if this feature of strtol & Co. is used in more places than CommandObjectMemoryWrite. If it was a common idiom then it might be nice to have direct support for it. But if it's just in one place, then hacking around it like this seems fine.<br>
><br>
> Jim<br>
><br>
>> On Apr 5, 2017, at 4:18 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>><br>
>> What if you write this:<br>
>><br>
>> // Explicitly try hex. This will catch the case where there is no 0x prefix.<br>
>> if (entry.ref.getAsInteger(16, uval64)) {<br>
>> // If that fails, let the algorithm auto-detect the radix. This will catch the case where there is a 0x prefix.<br>
>> if (entry.ref.getAsInteger(0, uval64)) {<br>
>><br>
>> Would that work? Alternatively, we could probably update the implementation of getAsInteger in LLVM to you to manually hint the radix AND prefix the number, as long as the prefix matches the hint.<br>
>><br>
>> On Wed, Apr 5, 2017 at 4:10 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
>>><br>
>><br>
>> 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:<br>
>><br>
>> OptionValueUInt64 &byte_size_value = m_format_options.GetByteSizeValue();<br>
>> size_t item_byte_size = byte_size_value.GetCurrentValue();<br>
>><br>
>> and to do some special magic for c-strings and the like. Somebody (not me) must have thought overloading "hex" format to mean "you can drop the 0x" was a tasty little side benefit.<br>
>><br>
>> But it's been that way forever, and I don't know who's relying on that behavior, so I'd rather not change it (intentionally) if we don't have to.<br>
>><br>
>> Jim<br>
>><br>
>>> On Wed, Apr 5, 2017 at 3:37 PM Jim Ingham via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
>>> memory write's argument ingestion was changed as part of the StringRefifying of Args so that we get:<br>
>>><br>
>>> (lldb) memory write &buffer 0x62<br>
>>> error: '0x62' is not a valid hex string value.<br>
>>><br>
>>> That seems unexpected and not desirable. What's going on is that the default format is hex, and if the format is hex, the command also supports:<br>
>>><br>
>>> (lldb) memory write -f x &buffer 62<br>
>>> (lldb) fr v/x buffer[0]<br>
>>> (char) buffer[0] = 0x62<br>
>>><br>
>>> The StringRef version of the args parsing is:<br>
>>><br>
>>> case eFormatDefault:<br>
>>> case eFormatBytes:<br>
>>> case eFormatHex:<br>
>>> case eFormatHexUppercase:<br>
>>> case eFormatPointer:<br>
>>> // Decode hex bytes<br>
>>> if (entry.ref.getAsInteger(16, uval64)) {<br>
>>><br>
>>> The problem is that passing "0x62" to getAsInteger with a radix of 16 rejects "0x62".<br>
>>><br>
>>> We do want to hint the radix. But it seems weird to reject an explicit indicator. Is there some clever way to use the StringRef functions to get the desired effect, or do I have to hack around this by manually stripping the 0x if I see it?<br>
>>><br>
>>> Jim<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> lldb-dev mailing list<br>
>>> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>