Re: cvs commit: apr/include apr_xlate.h
That's a real PITA. How exactly are we supposed to handle platforms this? Linux is getting warnings right now, which I dislike. I am developing on Linux (RedHat 7) and was getting warnings with the old code. I don't know why you are getting warnings from the explicit cast. Are you using an extra -Woption besides maintainer-mode and -Werror? Note that the first change I made did cause warnings, but I fixed those before you woke up this morning. The right way to handle it is to add an autoconf test that looks for the warning and sets a symbol accordingly. However, the code will work fine regardless of the warning, so it probably isn't worth the effort to support no warnings on anything but the latest gcc. Roy
Re: cvs commit: apr/include apr_xlate.h
That's a real PITA. How exactly are we supposed to handle platforms this? Linux is getting warnings right now, which I dislike. I am developing on Linux (RedHat 7) and was getting warnings with the old code. I don't know why you are getting warnings from the explicit cast. Are you using an extra -Woption besides maintainer-mode and -Werror? Note that the first change I made did cause warnings, but I fixed those before you woke up this morning. Nope, I'm on Mandrake 7.1, and I'm just using --with-maintainer-mode. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_xlate.h
Roy T. Fielding [EMAIL PROTECTED] writes: However, the code will work fine regardless of the warning, so it probably isn't worth the effort to support no warnings on anything but the latest gcc. you mean the latest glibc Previously, we had a warning on OS/390 and Tru64 (and I guess the level of glibc which comes with RH 7) because they had no const, and a clean compile everywhere else. I left it alone since their iconv() did not match the de facto standard and I didn't want to put in a cast that people on normal systems would not understand. I certainly didn't want a cast which would cause warnings. I had no qualms having the warning on Tru64 and OS/390 (not that many people build it on these platforms and it kept the code simpler). Now, most users (I'm guessing, but it seems like a safe guess) will see a warning, so something needs to be done. I'll look into using a different cast trick (or autoconf test) which will avoid the warning on all platforms. As long as there is a reasonable comment in the code I suspect people will live it alone (do you hear that Greg? :) ) Have fun... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: apr/include apr_xlate.h
[EMAIL PROTECTED] wrote:
fielding01/01/28 03:33:55
Modified:i18n/unix xlate.c
include apr_xlate.h
Log:
Revert last change and solve warning by explicit cast. The need would
have been obvious if dependencies were in the Makefile.
Revision ChangesPath
1.18 +2 -2 apr/i18n/unix/xlate.c
Index: xlate.c
===
RCS file: /home/cvs/apr/i18n/unix/xlate.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- xlate.c 2001/01/28 09:50:00 1.17
+++ xlate.c 2001/01/28 11:33:52 1.18
@@ -276,7 +276,7 @@
return APR_SUCCESS;
}
-apr_status_t apr_xlate_conv_buffer(apr_xlate_t *convset, char *inbuf,
+apr_status_t apr_xlate_conv_buffer(apr_xlate_t *convset, const char *inbuf,
apr_size_t *inbytes_left, char *outbuf,
apr_size_t *outbytes_left)
{
@@ -285,7 +285,7 @@
size_t translated;
if (convset-ich != (iconv_t)-1) {
-char *inbufptr = inbuf;
+char *inbufptr = (char *)inbuf;
char *outbufptr = outbuf;
Eh? Why are you casting away the const???
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: apr/include apr_xlate.h
Eh? Why are you casting away the const??? Because, as noted in the earlier commit, the iconv function does not have a const parameter, and the only reason this variable is being used is for passing that parameter. Blame it on whoever created the original iconv prototype for the single-unix spec. According to single-unix spec as I read it, there is a const: as found at http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html SYNOPSIS #include iconv.h size_t iconv(iconv_t cd, const char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft); Also, I now get warnings from this code that I didn't get before. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_xlate.h
size_t iconv(iconv_t cd, const char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft); That shows that SUSv2 is a descendant of XPG4 where this specific iconv interface (with const) originated. However, draft 5 of SUSv3 contains this prototype which has been aligned with C99: size_t iconv(iconv_t cd, char **restrict inbuf, size_t *restrict inbytesleft, char **restrict outbuf, size_t *restrict outbytesleft); That's a real PITA. How exactly are we supposed to handle platforms this? Linux is getting warnings right now, which I dislike. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_xlate.h
Btw, here is the reasoning for the change: http://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-group-lid=270 That's a real PITA. How exactly are we supposed to handle platforms this? Linux is getting warnings right now, which I dislike. Why is it a PITA? You should always be able to pass a char **. - Sascha
