iconv prototype (was: Re: lftp-pre3.0.0-20040115)
It seems that char** is correct, according to Ulrich Drepper: http://sources.redhat.com/ml/bug-glibc/2000-10/msg6.html I was under impression of the reverse, sorry about that. There was also some iconv discussion on abiword mailing list back in 2001: http://www.abisource.com/mailinglists/abiword-dev/01/August/0543.html -- Alexander. | http://www.yars.free.net/~lav/
Re: lftp-pre3.0.0-20040115
On Thu, Jan 15, 2004 at 09:51:22AM +0300, Alexander V. Lukyanov wrote: What's new: Had some trouble building from CVS: automake outputs: Makefile.am:3: AM_GNU_GETTEXT in `configure.ac' but `intl' not in SUBDIRS src/Makefile.am:42: variable `SOCKSLIBS' not defined The second is just an AC_SUBST. I'm not sure about the first, but it's apparently not fatal. My system has socklen_t, and socklen.m4 is defining lftp_socklen_t to nothing, instead of leaving it undefined. buffer.cc is missing errno.h. buffer.cc:307: error: invalid conversion from `const char**' to `char**' iconv takes a char**, not const char**. Now I'm getting make: *** No rule to make target `libpty.la', needed by `all-am'. Stop. I don't feel like stepping through libtool (this is why I hate libtool; it's brittle and impossible to diagnose). If config.log or something will help, let me know. -- Glenn Maynard Index: configure.ac === RCS file: /home/lav/cvsroot/lftp/configure.ac,v retrieving revision 1.19 diff -p -u -r1.19 configure.ac --- configure.ac17 Dec 2003 08:33:52 - 1.19 +++ configure.ac15 Jan 2004 08:22:10 - @@ -162,6 +162,7 @@ if test x$with_socksdante = xyes; then AC_CHECK_LIB(socks, main, [SOCKSLIBS=-lsocks], [AC_MSG_ERROR(cannot find -lsocks library)]) fi +AC_SUBST(SOCKSLIBS) LIBS=$LIBS $SOCKSLIBS if test -n $SOCKSLIBS; then AC_CHECK_FUNCS([Rpoll]) Index: m4/socklen.m4 === RCS file: /home/lav/cvsroot/lftp/m4/socklen.m4,v retrieving revision 1.3 diff -p -u -r1.3 socklen.m4 --- m4/socklen.m4 17 Dec 2003 06:37:42 - 1.3 +++ m4/socklen.m4 15 Jan 2004 08:22:10 - @@ -44,7 +44,7 @@ AC_DEFUN(TYPE_SOCKLEN_T, AC_LANG_POP(C++) ]) AC_MSG_RESULT($lftp_cv_socklen_t_equiv) + AC_DEFINE_UNQUOTED(lftp_socklen_t, $lftp_cv_socklen_t_equiv, +[type to use in place of socklen_t if not defined]) fi - AC_DEFINE_UNQUOTED(lftp_socklen_t, $lftp_cv_socklen_t_equiv, - [type to use in place of socklen_t if not defined]) ]) Index: src/buffer.cc === RCS file: /home/lav/cvsroot/lftp/src/buffer.cc,v retrieving revision 1.38 diff -p -u -r1.38 buffer.cc --- src/buffer.cc 14 Jan 2004 16:16:59 - 1.38 +++ src/buffer.cc 15 Jan 2004 08:22:13 - @@ -19,6 +19,7 @@ */ #include config.h +#include errno.h #include buffer.h #include xmalloc.h #include FileAccess.h @@ -303,7 +304,7 @@ try_again: store_size=buffer_allocated-(store_buf-buffer); const char *base_buf=put_buf; // do the translation - size_t res=iconv(backend_translate,put_buf,put_size,store_buf,store_size); + size_t res=iconv(backend_translate,(char**)put_buf,put_size,store_buf,store_size); in_buffer+=store_buf-(buffer+buffer_ptr+in_buffer); if(from_untranslated) untranslated-Skip(put_buf-base_buf);
Re: lftp-pre3.0.0-20040115
On Thu, Jan 15, 2004 at 03:23:52AM -0500, Glenn Maynard wrote: On Thu, Jan 15, 2004 at 09:51:22AM +0300, Alexander V. Lukyanov wrote: What's new: Had some trouble building from CVS: I have forgotten to commit some changes to CVS. Thanks for the fixes, I have applied them. The iconv case is the nastiest, since iconv should actually take const char** as source string. Makefile.am:3: AM_GNU_GETTEXT in `configure.ac' but `intl' not in SUBDIRS This is probably because of old version of automake. intl is optional now. -- Alexander.
Re: lftp-pre3.0.0-20040115
On Thu, Jan 15, 2004 at 07:14:10AM -0500, Glenn Maynard wrote: On Thu, Jan 15, 2004 at 02:19:41PM +0300, Alexander V. Lukyanov wrote: The iconv case is the nastiest, since iconv should actually take const char** as source string. I don't think so. Try this: #include string.h void func( const char **p ) { } main() { char *str = strdup(abc); func( str ); } test.cc:6: error: invalid conversion from `char**' to `const char**' It's actually the reverse. I.e. iconv on your system is declared as iconv(...,char **inbuf,...) while correct prototype is iconv(...,const char **inbuf,...) (If you can't figure out the reason for the above, I'll explain it, but it's far too late right now. :) I understand the reason. An autoconf test should be written to determine the iconv prototype and depending on that test a const cast should be used. BTW, if you install GNU libiconv which has correct iconv prototype, lftp would compile just fine. -- Alexander.
Re: lftp-pre3.0.0-20040115
On Thu, Jan 15, 2004 at 04:51:48PM +0300, Alexander V. Lukyanov wrote: I understand the reason. An autoconf test should be written to determine the iconv prototype and depending on that test a const cast should be used. I have found that AM_ICONV macro from gettext does the job and defines ICONV_CONST to const if the const is needed. So the cast become (ICONV_CONST char**)put_buf -- Alexander. | http://www.yars.free.net/~lav/
Re: lftp-pre3.0.0-20040115
On Thu, Jan 15, 2004 at 04:51:48PM +0300, Alexander V. Lukyanov wrote: #include string.h void func( const char **p ) { } main() { char *str = strdup(abc); func( str ); } test.cc:6: error: invalid conversion from `char**' to `const char**' It's actually the reverse. I.e. iconv on your system is declared as iconv(...,char **inbuf,...) while correct prototype is iconv(...,const char **inbuf,...) Not inherently, since then you couldn't pass a pointer to a buffer that *isn't* const, without another cast. That's what I was showing. Neither is correct--the desired constness can't be expressed in C++. -- Glenn Maynard
Re: lftp-pre3.0.0-20040115
On Thu, Jan 15, 2004 at 06:29:59PM +0300, Alexander V. Lukyanov wrote: I have found that AM_ICONV macro from gettext does the job and defines ICONV_CONST to const if the const is needed. So the cast become (ICONV_CONST char**)put_buf The safest way to do this is to use const_castconst char *(put_buf); it'll catch unwanted type changes, and doesn't need an autoconf test: it's harmless to do if not needed, since it'll still catch type errors. -- Glenn Maynard