On 2011-10-04 at 14:28 +0100, Dennis Davis wrote: > OpenBSD also reports: > > cc rfc2047.c > rfc2047.c: In function 'rfc2047_decode2': > rfc2047.c:260: warning: passing argument 2 of 'libiconv' from incompatible > pointer type
That would be: (void)iconv(icd, (ICONV_ARG2_TYPE)(&dptr), &dlen, CSS &outptr, &outleft); Here, the type depends upon the OS. The default, if not overriden, is: #define ICONV_ARG2_TYPE const char ** The per-OS os.h can change it, as can Local/Makefile. The most common alternative appears to be: #define ICONV_ARG2_TYPE char ** The http://www.openbsd.org/cgi-bin/man.cgi man-page viewer does not report any man-pages for iconv, so at a guess this is coming from Ports' libiconv: http://www.openbsd.org/cgi-bin/cvsweb/ports/converters/libiconv/ in which the Makefile is explicitly setting: CONFIGURE_ENV= am_cv_proto_iconv='extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);' So OpenBSD is overriding the function prototype at build time, to declare an input buffer to be non-const; that seems strange, I thought the only reason people did that was to not worry about type safety, which is counter to the OpenBSD ethos. So, investigate further ... Cloning git://git.savannah.gnu.org/libiconv.git I see that the type of that parameter in iconv.h.in is: @ICONV_CONST@ char* * inbuf And grep'ing for that reveals: ----------------------------8< cut here >8------------------------------ 2007-05-27 Bruno Haible <[email protected]> Follow broken iconv() prototype in POSIX. * configure.ac (ICONV_CONST): Set to empty if the system has no iconv. * lib/config.h.in (ICONV_CONST): Change default value to an empty comment. * src/iconv.c (ICONV_CONST): Change default value to empty. Reported by Andreas Krennmair <[email protected]>. ----------------------------8< cut here >8------------------------------ And this is why I have a love/hate relationship with POSIX. It comes so close and does at least set a common baseline of functionality, but keeps getting screwed over by vendor politics. Seriously, they dropped the const? _Why_? At this point, I declare: * it's a warning, it still builds * so it's not worth risking breakage elsewhere by changing at this stage in the RC process * for 4.78, we should invert the default to be non-const and let some platforms override to be const as needed, although I suspect that will be unnecessary. * I'm pouring myself a whiskey > OpenBSD also suggests: > > strcpy() is almost always misused, please use strlcpy() > sprintf() is often misused, please use snprintf() > strcat() is almost always misused, please use strlcat() > > in a few places. Details on request. Is often mis-used, but is not in Exim. They've been very carefully checked, on multiple occasions. strlcpy/strlcat are excellent functions which I use myself in new code, where I'm prepared to state "the porter has to provide a libc with them, or add the functions". In this case, Exim is handling the strings just fine. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
