Re: [RFH] NetBSD 6?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

>>  [OLD_ICONV]

> 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.


Attachment: pgpQ4tewmECpu.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]