Am Mit, 2004-11-17 um 06.04 schrieb Frank Zago:
> Frank Zago wrote:
> >=20
> >>
> >> The SANE standard defines the comunication between frontend and back=
end.
> >> It does not define any structs that shall be internally used by the
> >> frontend or backend.
> >>
> >> I think the clean appoach is that the backend handles the texts inte=
rnal
> >> as non const strings and only creats the SANE_Device struct to retur=
n
> >> the data to the frontend. The SANE_Device struct is defined for the
> >> purpose to transfer the data from the backend to the frontend as con=
st
> >> chars. When the backend has to use non const definitions then it is =
not
> >> allowed to use the SANE_Device struct so it has to use it=C2=B4s own=
data
> >> types and not the one of the SANE standard.
> >>
> >> Oliver
> >=20
> >=20
> > So, in that case what about the patch in attachment.
> >=20
> > I've also changed the internal definition of SANE_Option_Descriptor f=
or=20
> > the same reason. It breaks about 5 backends, but they can all be eas=
ily=20
> > fixed by hand by removing a few const. I'd say that the current=20
> > definition of SANE_Device and SANE_Option_Descriptor and created an u=
gly=20
> > cascade of unnecessary casts and consts in all the backends.
> >=20
> > Frank.
> >=20
> >=20
> >=20
> > ---------------------------------------------------------------------=
---
> >=20
> > Index: include/sane/sane.h
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > RCS file: /cvsroot/sane/sane-backends/include/sane/sane.h,v
> > retrieving revision 1.6
> > diff -u -3 -p -B -b -u -r1.6 sane.h
> > --- include/sane/sane.h 13 Nov 2004 20:29:14 -0000 1.6
> > +++ include/sane/sane.h 14 Nov 2004 18:59:03 -0000
> > @@ -92,6 +92,16 @@ typedef enum
> > }
> > SANE_Unit;
> > =20
> > +#ifdef BACKEND_NAME
> > +typedef struct
> > + {
> > + SANE_String name; /* unique device name */
> > + SANE_String vendor; /* device vendor string */
> > + SANE_String model; /* device model name */
> > + SANE_String type; /* device type (e.g., "flatbed scanner") */
> > + }
> > +SANE_Device;
> > +#else
> > typedef struct
> > {
> > SANE_String_Const name; /* unique device name */
> > @@ -100,6 +110,7 @@ typedef struct
> > SANE_String_Const type; /* device type (e.g., "flatbed
> > scanner")=
*/
> > }
> > SANE_Device;
> > +#endif
> > =20
> > #define SANE_CAP_SOFT_SELECT (1 << 0)
> > #define SANE_CAP_HARD_SELECT (1 << 1)
> > @@ -134,6 +145,28 @@ typedef struct
> > }
> > SANE_Range;
> > =20
> > +#ifdef BACKEND_NAME
> > +typedef struct
> > + {
> > + SANE_String name; /* name of this option (command-line name) */
> > + SANE_String title; /* title of this option (single-line) */
> > + SANE_String desc; /* description of this option (multi-line) */
> > + SANE_Value_Type type; /* how are values interpreted? */
> > + SANE_Unit unit; /* what is the (physical) unit? */
> > + SANE_Int size;
> > + SANE_Int cap; /* capabilities */
> > +
> > + SANE_Constraint_Type constraint_type;
> > + union
> > + {
> > + SANE_String *string_list; /* NULL-terminated list */
> > + SANE_Word *word_list; /* first element is list-length */
> > + SANE_Range *range;
> > + }
> > + constraint;
> > + }
> > +SANE_Option_Descriptor;
> > +#else
> > typedef struct
> > {
> > SANE_String_Const name; /* name of this option (command-line
> > nam=
e) */
> > @@ -154,6 +187,7 @@ typedef struct
> > constraint;
> > }
> > SANE_Option_Descriptor;
> > +#endif
> > =20
> > typedef enum
> > {
>=20
>=20
>=20
> SO? Is anyone for or against this patch?
>=20
Hello Frank.
I am not a fan of this patch.
I think it will work but I think it is a hack.
It seems that only a few backends have problems with this.
Why not fix it in a proper way:
create the strings as non const and then set the
sane_device structur to point to these strings?!
But when I am the only one who is against this patch
then I will be quiet and it will be ok for me. It is nothing
that will steal my sleep :)
Oliver
