[sane-devel] broken sane-config in sane-backends version 1.1.0
olaf.meeuwissen at avasys.jp
Thu Mar 5 23:22:05 UTC 2009
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
> 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.
> 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
> 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().
Hope this helps,
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962 Help support software freedom
More information about the sane-devel