[sane-devel] broken sane-config in sane-backends version 1.1.0

[m. allan noah]

On Thu, Mar 5, 2009 at 6:22 PM, Olaf Meeuwissen
<olaf.meeuwissen at avasys.jp> wrote:
> szukw000 at arcor.de writes:
>
>> As xsane needs SANE_CAP_ALWAYS_SETTABLE in xsane-0.996/src/xsane-back-gtk.c,
>> I had changed:
>>
>> --- include/sane/sane.h.orig  2009-03-01 20:41:13.000000000 +0100
>> +++ include/sane/sane.h       2009-03-01 20:41:41.000000000 +0100
>> @@ -112,6 +112,7 @@
>>  #define SANE_CAP_AUTOMATIC           (1 << 4)
>>  #define SANE_CAP_INACTIVE            (1 << 5)
>>  #define SANE_CAP_ADVANCED            (1 << 6)
>> +#define SANE_CAP_ALWAYS_SETTABLE    (1 << 7)
>>
>>  #define SANE_OPTION_IS_ACTIVE(cap)   (((cap) & SANE_CAP_INACTIVE) == 0)
>>  #define SANE_OPTION_IS_SETTABLE(cap) (((cap) & SANE_CAP_SOFT_SELECT) != 0)
>>
>>>Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>>>
>>>Please note that SANE_CAP_ALWAYS_SETTABLE is _not_ part of the current
>>>stable API
>>
>> I found the value in sane-backends-1.0.19/include/sane/sane.h in line 111.
>> And I found the value in sane-backends-1.0.9/include/sane/sane.h in line 103.
>>
>> Are all these versions _not_ part of the stable API ?
>
> Not of the _documented_ stable API.
>

szukw000- dont confuse the SANE API with the SANE software. The latter
is an imperfect implementation of the former. Sometime weird things
creep in, and they are fixed later. In this case, I found that #define
and removed it, but not before the author of XSane decided to use
it...

>> By the way, compiling sane-backends-2009-03-02 gcc-4.3.3 warned several times:
>>
>> passing argument 1 of 'free' discards qualifiers from pointer target type
>>
>> Visiting the reported lines I found that the
>>
>> SANE_Device.{name,vender,model}
>>
>> were freed although they are 'SANE_String_Const'. Is it correct to free
>> constants? A list of files is shown below.
>
> That depends.  If they are pointers to dynamically allocated memory
> (and they are freed by the _owner_ of the SANE_Device), it's okay.  If
> they are pointers to string literals, it's not.  For those places
> where the free is okay, one really should cast the const away before
> passing the pointer to free().

allan
-- 
"The truth is an offense, but not a sin"