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