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?
