Re: "discards qualifiers from pointer target type" in ltdl.c

[Ralf Wildenhues]

Hi Stefaan,

* Stefaan wrote on Thu, Aug 18, 2005 at 12:06:10PM CEST:
> > Only if a clean fix is possible, fixes it on all kinds of compilers
> > while not introducing new warnings (or failures!  Yes, I've managed
> > to do that once!) on others, and rather not for branch-1-5.  Of course,
> > warnings that show actual bugs are a different matter altogether.
> 
> Why the exemption of branch-1-5 if I may ask? Just out of curiosity really. 

I'd rather put only bug fixes into branch-1-5.  It's a habit you acquire
after being burnt with regressions.

> > Surely.  Then you'll have the warning within the strrchr replacement
> > implementation.  SUSv3 specifies it with "char *" as you suggest.
> True, but...
> You have preprocessor code to choose between three different
> implementations for your strrchr: (taken from gnu man pages)
>        char *strrchr(const char *s, int c);
>        char *rindex(const char *s, int c);
> and finally your own:
>        const char *strrchr LT_PARAMS((const char *str, int ch));
> 
> Though I have the feeling taking const char * as an argument, and
> returning a char * derived from that is faulty, it seems to be the
> prescribed standard, and declaring the self-implemented strrchr to
> return const char * then seems just a way to move the compiler
> warnings out of the strrchr function itself, and towards the functions
> that call it.

ACK.

> My suggestion would then be to change the strrchr implementation at
> line 363.  In my local version, I change return q into return (char *)
> q (shiver, replacing evil by other, but less harmful evil). That
> seemed to solve the issue on my local version.  I have no idea how
> other (non-gcc) compilers will take this, but I have the possibility
> of testing on tru64, solaris and hpux if wanted.

If you produce a (also non-gcc) tested patch, ok.  This change seems
rather benign.

Cheers,
Ralf