Greg Troxel <gdt%ir.bbn.com@localhost> writes: > The difficulty git is having (I think) is that it is compiling a test > program with the POSIX declaration, and that test program fails to > build. It is likely be that our iconv would be fine with the actual git > code. So perhaps a different autoconf test is in order. So I think > this is an example of the same class of problem as "portably pass around > pointers", where strict type matching by the compiler fails. But I > don't understand how this works with GNU iconv. It turns out this is more subtle. James suggested that "const char **" as an argument type was not problematic, because a "char **" would be promoted. That observation seemed entirely correct and reasonable to me. But the promotion actually does cause a warning. My local C99 language lawyer explained that this promotion is strictly speaking improper (perhaps because the function could change the pointer to point to a string constant, which could then be attempted to be written by the caller), even though in any sane program it's fine. In git, the OLD_ICONV ifdef is used precisely to avoid this warning, by using the platform-appropriate type for the variable used to pass the input. Amusingly, git's wrapper function take "const char *in" as the input parameter, and ends up casting that to char * if OLD_ICONV is *not* defined. So indeed, git's code is better in the OLD_ICONV situation.
Attachment:
pgpdYxE4XUNPl.pgp
Description: PGP signature