T.SHIOZAKI wrote:

>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):
>  http://mail-index.netbsd.org/tech-userlevel/2004/07/
>
>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.
>
>--
>Takuya SHIOZAKI
>

Unfortunately, the first thing that doesn't build is NetBSD itself 
(linintl)...

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 
<http://www.netbsd.org/Goals/standards.html>: "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,

-- 
	Pappires

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