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 <bruno@???>
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 <ak@???>.
----------------------------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
