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
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
