> 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. > You mean branch-1-5, right? Yes > 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. 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. Cheers, Stefaan _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool