> On Feb 16, 2015, at 10:11 AM, Zachary Turner <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
> _______________________________________________
> lldb-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
Thanks,
- Enrico
📩 egranata@.com ☎️ 27683
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
