Re: [GNC-dev] Problems with python 3 and the gnucash python bindings.

2018-07-12 Thread Derek Atkins
John Ralls  writes:

>> PS. Another solution would be to force byte string only arguments for
>> python 3 using a SWIG define SWIG_PYTHON_STRICT_BYTE_CHAR.
>> 
>> This would require a major re-write of the gnucash_core.py to perform the
>> unicode<->byte transformations.
>
> ISTM it would be better to fix qof_query. It shouldn't be assuming
> that just because it has typedeffed const char* to "QofIdTypeConst"
> that it will necessarily get a statically allocated char* that is safe
> to keep. There's absolutely nothing preventing it from being a stack
> or heap object (stack is more likely in C, as in
>   QofIdTypeConst type = "book"; 
>   qof_query_search_for(query, type);
> ) that will cause the same crash.

I disagree -- the API specification is clear that it will store the
pointer, so callers need to know this.

When it moves to C++ you can just use std::string.  :)

> There are probably other cases where someone has made the same bad
> assumption and stored an unduplicated char*, though I hope none quite
> so egregious.
>
> Please file a bug: https://wiki.gnucash.org/wiki/Bugzilla
>
> Regards,
> John Ralls

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Problems with python 3 and the gnucash python bindings.

2018-07-12 Thread John Ralls


> On Jul 12, 2018, at 7:23 AM, Derek Atkins  wrote:
> 
> John Ralls  writes:
> 
>>> PS. Another solution would be to force byte string only arguments for
>>> python 3 using a SWIG define SWIG_PYTHON_STRICT_BYTE_CHAR.
>>> 
>>> This would require a major re-write of the gnucash_core.py to perform the
>>> unicode<->byte transformations.
>> 
>> ISTM it would be better to fix qof_query. It shouldn't be assuming
>> that just because it has typedeffed const char* to "QofIdTypeConst"
>> that it will necessarily get a statically allocated char* that is safe
>> to keep. There's absolutely nothing preventing it from being a stack
>> or heap object (stack is more likely in C, as in
>>  QofIdTypeConst type = "book"; 
>>  qof_query_search_for(query, type);
>> ) that will cause the same crash.
> 
> I disagree -- the API specification is clear that it will store the
> pointer, so callers need to know this.
> 

Where? The Doxygen comment is:

/** Set the object type to be searched for.  The results of
 *  performing the query will be a list of this obj_type.
 */
void qof_query_search_for (QofQuery *query, QofIdTypeConst obj_type);

Not only silent about storing a pointer, it even hides the fact that it’s a 
pointer at all. One has to go look at the typedef for QofIdTypeConst in qofid.h 
to see that it’s a const char *. 

> When it moves to C++ you can just use std::string.  :)

An enum would be safer, faster, smaller, more intuitive, and wouldn’t break 
swig.

Regards,
John Ralls 

> 
>> There are probably other cases where someone has made the same bad
>> assumption and stored an unduplicated char*, though I hope none quite
>> so egregious.
>> 
>> Please file a bug: https://wiki.gnucash.org/wiki/Bugzilla
>> 
>> Regards,
>> John Ralls
> 
> -derek
> -- 
>   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>   Member, MIT Student Information Processing Board  (SIPB)
>   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
>   warl...@mit.eduPGP key available

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel