bsd/citrus iconv

[Gabor Kovesdan]

Em 17-02-2012 17:19, Dag-Erling Smørgrav escreveu:
> Andriy Gapon<avg at FreeBSD.org>  writes:
>> But nothing precludes it from being a separate library in principle?
>> There is even src/lib/libiconv, it's just not connected to the build.
> You're right - for some reason, I thought src/lib/libiconv was just a
> Makefile for GNU libiconv.
POSIX requires iconv() to be in libc. However, a glue Makefile was 
provided there for testing purposes.
>
> However, it would be a lot of work for relatively little gain, which
> would then have to be backed out when citrus went "live".
Not that much work, I think. We have to just enable to build that 
library and install the header with a different name. The base iconv.h 
is designed to support builds for GNU libiconv but in practice there may 
be problems with that.
>
> Gabor, do you have a list of known issues?
1, iconv() does not correctly return the number of non-identical 
conversions.

2, lang/gcc* build problems (potentially related to iconv.h including 
stdbool.h and iconv() being defined as a macro)

3, mutt-devel fails to build. It uses the above check where bsd iconv 
returns 1, while GNU returns 0:

| #include<iconv.h>
| int main()
| {
|   iconv_t cd;
|   char buf[4];
|   char *ob;
|   size_t obl;
|   ob = buf, obl = sizeof(buf);
|   return ((cd = iconv_open("UTF-8", "UTF-8")) != (iconv_t)(-1)&&
|           (iconv(cd, 0, 0,&ob,&obl) ||
|            !(ob == buf&&  obl == sizeof(buf)) ||
|            iconv_close(cd)));
| }

4, Check and fix locking in citrus_mapper.c.

5, (not strictly a problem) Citrus iconv has been designed to be modular 
and extensible. So it uses dynamically loadable modules extensively, at 
two abstraction levels. However, it is not that practically useful 
because (1) probably it won't be further extended as Unicode is becoming 
standard and probably there won't be shiny new encodings and (2) even if 
it is extended, it is totally fine to require a complete rebuild. So it 
would be probably better to just link all of that stuff to libc. It 
would spare the overhead of modularity and clean up a bunch of .so files 
that are installed currently if iconv is enabled.

Gabor