Greg Troxel <gdt@xxxxxxxxxx> writes: > 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. Interesting. Don't get too offended by the "OLD_" prefix to that symbol, by the way. I do not think "old" means "old and broken hence fixed in newer version and you are low life if you live on a platform that has to define it" ;-). We just needed to have a boolean to tell which variant it is to let the compiler build objects without complaining, and we named that switch as OLD_ICONV. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html