Subject: Re: HEADS UP: iconv(3) prototype was changed
From: Paulo Alexandre Pinto Pires <>
List: current-users
Date: 08/02/2004 08:26:52

>I changed the iconv(3) function interface to follow the POSIX specification;
>the 2nd argument is changed to "char ** restrict" instead of
>"const char ** restricted".
>For the details, see the thread called "iconv(3) prototype" in
>the tech-kern@ list (from 07/26/2004):
>This change may make some programs (including pkgsrc-ed ones) unable to
>be built.  Please change such programs if necessary.
>BTW, I will request to pull up it to 2.0 one of these days.

Unfortunately, the first thing that doesn't build is NetBSD itself 

I understand and most often advocate adherence to standards, but isn't 
POSIX just semantically *wrong* in this case?  I wouldn't be surprised 
if a future revision of SUS/POSIX would actually fix this, especially 
when big players in the UNIX{,-like} market, like Solaris and Linux, do 
what makes more sense.  I have read the discussion on tech-userland, but 
cannot avoid quoting NetBSD's own statement at 
<>: "NetBSD is extremely close 
to being POSIX.1 compliant (...). There are a few nits we know about: 
some we plan to fix, and others we plan to ignore until a future 
revision of POSIX ``fixes'' them for us."

Please notice that, unless converting statically compiled strings, the 
second argument to iconv() is very likely to be a second pointer into 
somewhere in a buffer whose head pointer is in another variable (which, 
in real world applications, has probably come from malloc() at some 
point).  If buffer is (char *), it is clean and safe to have "const char 
*sec_ptr=buffer; iconv(cd, &sec_ptr,...);", as we used to do.  However, 
if buffer is (const char *), it is unclean and potentially unsafe to 
write "char *sec_ptr=(char *)buffer; iconv(cd, sec_ptr,...);",as POSIX 
would require.

So far, this move is just making NetBSD less compatible with real world 
existing implementations and applications.  I don't know if the the 
additional work of porting non-compliant but otherwise correct 
applications would pay off.  I don't have access to AIX or HPUX machines 
to know if they adhere to POSIX here, but I have the feeling that the 
majority of the applications we port to NetBSD are not developed in 
those two, anyway.

Best regards,


... Qui habet aurem audiat quid Spiritus dicat ecclesiis.