Thread (1 message) 1 message, 1 author, 2016-06-15
  • (off-list ancestor, not in this archive)
  • Re: [RFH] NetBSD 6? · Greg Troxel <hidden> · 2016-06-15

Re: [RFH] NetBSD 6?

From: Greg Troxel <hidden>
Date: 2016-06-15 22:55:41

Junio C Hamano [off-list ref] writes:
quoted
 [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.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help