[sane-devel] [patch] fix SANE_Device

[Oliver Rauch]

Am Sam, 2004-11-13 um 23.36 schrieb Frank Zago:
> Oliver Rauch wrote:
> > Am Sam, 2004-11-13 um 21.26 schrieb Frank Zago:
> > 
> > 
> >>>I guess the idea was that the strings shouldn't be changed after the
> >>>SANE-Device pointer is returned to the frontend.
> >>
> >>Thsi behaviour should be made clear in the doc. To me, const means something else.
> >>Since this patch makes the variable from const to non-const, I don't think it 
> >>will break anything.
> >>
> >>
> >>>As far as I can see the trouble results from doing things like
> >>>sane.name = strdup (...) and freeing those in sane_exit().
> >>>
> >>
> >>That is correct. I think it's clear from the use of that field that the const 
> >>creates more trouble than it solves.
> > 
> > 
> > Hello Henning, hello Frank,
> > 
> > I think the const should not be changed because of two reasons:
> > 
> > 1) It makes sense to define it as const in the standard because
> >    the frontend should not change anything in the struct that
> >    is returned by the backend
> > 2) It is part of the sane standard and it makes a lot of problems
> >    to change the standard definitions
> > 
> > May be we need a second definition without the const in some cases,
> > but the struct that is returned by the backend should contain const
> > strings.
> > 
> > So when it is necessary then the routine that needs any non const
> > strings has to create its own struct definition.
> > 
> > May be this second (non const) definition can be put in a helper file
> > (sanei_???.h).
> > 
> > Oliver
> > 
> > 
> 
> So what about having an external definition for frontends, and one internal for 
> backends?

Please can you explain what error/warning the const produces on your
system?

I think it should be possible to change the pointers, call free(...)
etc. The const definition should make sure that it is not possible to
change the contents of the strings (pointer to const char, not const
pointer to char).

So I think there is no need to add anything in the backend. It would be
enough when the backend creates a non const string and makes the pointer
in the struct point to the non const string - may be with a typecast,
but I think the typecast is not necessary.

Oliver