[lldb-dev] Possible bug in the LLDB Python Scripting Example (And the API itself)

[Enrico Granata]

> On Feb 16, 2015, at 10:11 AM, Zachary Turner <zturner at google.com> wrote:
> 
> The issue is that the example on the website is broken because it checks GetValue() == None. So either the example is wrong

I would posit that the example is wrong - I don’t think anyone updated it in the longest time, definitely not me

> or the implementation is wrong. Checking GetValue() against None is the intuitive thing one would do though, so it seems desirable to make that work

I disagree.

In our API, generally, an answer of None means “could not compute this” - for instance, your SBValue refers to a variable that is out of scope, or is outright invalid
Conflating the case of “I could compute this, the answer is 0” with “I could not compute this” feels wrong - also, imagining this from the perspective of, say, an IDE, it makes for more convoluted code:

value = obj.GetValue()
if value == None:
	if value.IsValid(): value = “NULL” #argh - None now means two things!!!!!

I would also recommend against GetValue() for numeric comparisons - I think even right now, that API returns “NULL” the string for null pointers and “nil” for the ObjC version thereof - and if we could reliably tell C++ >= 11, I would have no objection to making it return “nullptr” when applicable
If you need a numeric value to compare - GetValueAsSigned/Unsigned() are the APIs to go to - and even those should NOT return None to mean NULL, but the correct bit pattern to mean NULL on the underlying system (which we are assuming to be 0 :-)

> On Mon, Feb 16, 2015 at 9:19 AM Enrico Granata <egranata at apple.com <mailto:egranata at apple.com>> wrote:
> I may be clearly misunderstanding what you are trying to say here, but my expectation is that given
> 
> T *ptr = nullptr;
> 
> the way to check if "ptr" is a nullptr would be
> 
> sbvalueForPtr.GetValueAsUnsigned() == 0
> 
> given that sbvalueForPtr.GetType().IsPointerType() is true
> 
> As for the special case of a shared_ptr<>, that is a class that has an instance variable of pointer type. To check for NULL-ness, you're gonna have to retrieve the child. That requires you to have some knowledge of the internals of your standard C++ library.
> 
> An alternative would be (and I am not sure if that is plugged in at the moment - if not feel free to ask for it, or provide a patch to that effect) to use the recently added ability for synthetic children to provide a numeric value. One could imagine wiring things up so that the shared_ptr<>'s value is the underlying pointer value. Then no child fetching would be required.
> 
> Sent from my iPhone
> 
> On Feb 15, 2015, at 11:23 PM, Spundun Bhatt <spundun at gmail.com <mailto:spundun at gmail.com>> wrote:
> 
>> (Using OSX 10.10.1, XCode 6.1.1 6A2008a, lldb-320.4.156, Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) )
>>  
>> Hi all,
>> I have just started using LLDB and its Python scripting interface.
>> 
>> I may have stumbled upon a deep bug related to null pointer treatment.
>> 
>> http://lldb.llvm.org/scripting.html <http://lldb.llvm.org/scripting.html> I tried to follow this scripting tutorial.
>> 
>> http://pastebin.com/S0RhVG3s <http://pastebin.com/S0RhVG3s> This is the output of my interaction with the lldb and the python script. (I haven't modified any part of the example code there)
>> 
>> It seems like `if left_child_ptr.GetValue() == None:` expression (and other similar expressions) doesn't evaluate to true for null pointers
>> 
>> I was able to cook up a python check for null pointer:
>> 
>> def IsNullPtr(ptr):
>> 
>>   ptr_string = str(ptr.GetValue())
>> 
>>   if re.search('[1-9a-fA-F]', ptr_string):
>> 
>>     return False;
>> 
>>   else:
>> 
>>     return True;
>> 
>> I discussed this on the irc channel and zturner thought it looked like a bug and that I should post it here.
>> 
>> Hope this helps.
>> Please let me know if there is a standard way to do null pointer check through the python API. Especially a check for nullptr shared_ptrs.
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150216/7ac949d9/attachment.html>