Re: [RFH] NetBSD 6?

From: Greg Troxel <gdt@ir.bbn.com>
Date: Jan 8, 2013, 18:53 UTC
Message-ID: <rmiobgz4icr.fsf@fnord.ir.bbn.com>
In-Reply-To: <7vvcbew895.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

>>  [OLD_ICONV]

Show 5 quoted lines

> It refers to the type of the second parameter to iconv(); OLD_ICONV
> makes it take "const char *", as opposed to "char *", the latter of
> which matches
>
>   http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html

I just wanted to follow up on this. It turns out that the old POSIX standard was buggy (header file and function spec were different), and they resolved it in favor of non-const. NetBSD followed the const way, and just now documented that with links to the standards email archives.

Interestingly, GNU iconv 1.14 seems to define it as const also:

  https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html

(which matches man/iconv.3 in the tarball).

When I build libiconv-1.14, it produces a .h with const. But it has a configure test to check if there is a host include file with const, and puts the const in the built header file or not to match! In include/iconv.h.in, there is:

  extern size_t iconv (iconv_t cd,
      @ICONV_CONST@ char* * inbuf, size_t *inbytesleft,
       char* * outbuf, size_t *outbytesleft);

Someday, it would be nice to have the configure test not fail an iconv implementation just because of the const, unless the presence of const is causing a real problem. But I can understand that no one thinks that's important enough to get around to.