> Actually, all the changes should be internal to our own code. Functions
> that take const char pointers can still send non-const pointers. The
> errors would be generated if we changed the return value of the library
> functions, not the arguments.
>
> Not that I don't think that return values should be changed where it
> is appropriate as well but this change doesn't do that.
>
...
> > if we want to take const-safety seriously the effects will ripple
> > throughout the code...
>
> I would love to see const-safety given more attention but certainly
> we should make sure our external interfaces are correct so that people
> writing to them have the opportunity to do full error checking.
These are good points. Can you post the patch again? I deleted it.
Sounds like it would be safe. I am interested in const-ify-ing the
backend code, if possible. It does offer a level of code checking that
we don't currently have.
The only issue is that is has to be done pretty exhaustively. If you
don't, your new const function parameters start passing params to
functions that takes non-const params, and warnings start to fly.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
