Re: Cast abuse

[Brian Stafford <brian stafford uklinux net>]

On Mon, 19 November 20:16 Peter Bloomfield wrote:
> On 2001.11.19 11:08 Toralf Lund wrote:
> ...
>> Can the str...() declarations be assumed to use "const" properly on all 
>> platforms? I seem to remember that _all_ string arguments had type "char *" 
>> on some of our systems in a not-to-distant past.
>> 
>> - Toralf
> 
> There does seem to be a problem with iconv:
> 
> ICONV(3)            Linux Programmer's Manual            ICONV(3)
> 
> NAME
>        iconv - perform character set conversion
> 
> SYNOPSIS
>        #include <iconv.h>
> 
>        size_t iconv (iconv_t cd,
>                      char* * inbuf, size_t * inbytesleft,
>                      char* * outbuf, size_t * outbytesleft);
> 
> where inbuf is often passed from a const char * variable.  There are a 
> couple of files in libmutt that do this, and gcc gripes each time it sees 
> them.  I imagine that's why the casts that Brian complained about in the 
> ldap code were there.

I just checked glibc 2's iconv.h and the one distributed with GNU libiconv.  
Both declare inbuf to be const.  SUSv2 declares it const too.  So I'd say the 
linux man page is incorrect.

> I've never seen the code for iconv, so I don't know for sure whether it will 
> ever change the contents of inbuf, but the man page indicates that it 
> doesn't.

In libiconv-1.6.1, there is a LIBICONV_CONST variable which is substituted in 
iconv.h.in during installation.  Presumably the idea is to match the iconv.h 
distributed with the target system.  In any case, the buffer is not modified.

> What's the appropriate way to code a call to it? Can one override the 
> prototype to properly show that inbuf is a const argument?

Could be tricky.  One solution might be that used in libxml2, there is a macro 
with a name like BAD_CAST which is empty on systems with working compilers and 
the correct prototypes, otherwise it is defined to an appropriate cast.  The 
macro is still as ugly as the cast but at least it doesn't override compiler 
assumptions or disable warnings when it is empty.  Another solution is to 
supply the correct declarations for the iconv functions in a private iconv.h 
and ignore the constless iconv.h supplied with the system.  I'm fairly sure 
autoconf can detect whether the iconv functions are declared properly.  If a 
system supplies an iconv that does modify the buffer, I'd say configure should 
refuse to proceed since installing GNU libiconv will fix this problem.

Brian