Re: Python pretty-printing [5/6]

[Phil Muldoon <pmuldoon at redhat dot com>]

Thiago Jung Bauermann wrote:
> El miÃ, 08-04-2009 a las 18:52 -0600, Tom Tromey escribiÃ:
>   
> > I looked again and I don't see how it can return NULL without setting
> > the exception.  Can you point it out to me?
> >     
>
> I found one potential problem, which could cause the function to return
> NULL without an exception being set (it's not the case I thought of
> before, I think): suppose there's no objfile Python object when this
> function is called, to the ALL_OBJFILES loop will skip all objs, then
> the gdb module has no pretty_printers attribute, or the pretty_printers
> value is not a list object. In that case, the function will return NULL
> without a Python exception being set. Can it happen?
>
>   


This would require the gdb.pretty_printers attribute in the code to be 
changed from a list to something else (or removed for the not existing 
scenario).  Anyway it would require a conscious code change on behalf of 
another author, and not an environmental change. It could happen if 
somebody changed the code, but I suspect (in this scenario) it would 
fail long before it reached here.


> Also, I noticed that the function may return Py_None if no
> pretty-printer is found, and the callers even expect that. The function
> comment needs to be fixed then:
>
> /* Find the pretty-printing constructor function for TYPE.  If no
>    pretty-printer exists, return NULL.  If one exists, return a new
>    reference.  */
>
>   


Yes, my fault.  Missed this :(


> > Thiago> Because of this, pretty_print_one_value can now probably just call
> > Thiago> convert_value_from_python and return a struct value in all cases and be
> > Thiago> done with it. Either this function should be changed to work that way,
> > Thiago> or the comment above removed.
> >
> > I made the minimal change here.  I don't want to refactor this right
> > now; Phil is in the middle of doing that for the embedded \0 problem.
> > We can apply his fix separately; the current code is not ideal, due to
> > this problem, but it is still usable for a variety of printers.
> >     
>
> Fine with me.
>
>   


I'm in the middle of this right now. I'm putting the finishing touches 
on the optional string fetch parameter from the comments posted to the 
archer list, and will start work on fixing string output.


Regards

Phil