Frank Zago wrote:
>=20
>>
>> The SANE standard defines the comunication between frontend and backen=
d.
>> 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 intern=
al
>> as non const strings and only creats the SANE_Device struct to return
>> 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 const
>> chars. When the backend has to use non const definitions then it is no=
t
>> allowed to use the SANE_Device struct so it has to use it=C2=B4s own d=
ata
>> 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 for=
=20
> the same reason. It breaks about 5 backends, but they can all be easil=
y=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 ugl=
y=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 name)=
*/
> @@ -154,6 +187,7 @@ typedef struct
> constraint;
> }
> SANE_Option_Descriptor;
> +#endif
> =20
> typedef enum
> {
SO? Is anyone for or against this patch?
