[illumos-Developer] BSD iconv (was Closed-bin accords of the OpenSolaris conference... )

[Gabor Kovesdan]

Em 2010.08.10. 23:57, Joerg Schilling escreveu:
> OK, then let us start with a design discuccion.
>
> We could create iconv_open()/iconv_close()/iconv() stub replacements for libc
> and dlopen() the FreeBSD implementation in case it is needed. As the standard
> interfaces in iconv.h define only a iconv_t as a pointer, there is no
> implcit dependency on structure sizes.
>    
Why to make stub implementations? The main code of FreeBSD's iconv 
resides in libc, only the pluggable conversion modules are implemented 
as shared libraries. Those 3 calls are already designed to be added to libc.
> As we have the FreeBSD developer in the list of recipients, let me ask
> something:
>
> 	Would it be possible to convert the code to be as POSIX compliant as
> 	possible? From looking at iconv.c, this would e.g. mean:
>
> 	-	Do not include<sys/cdefs.h>  as this is something that does
> 		not exist officially. Solution for FreeBSD:
>    
I don't know what it actually does but as per style(9) we need it in 
each file and I think it has something to do with the __FBSDID macro 
that probably we will use before committing the code. Besides, it must 
be included first, so a hidden include would not do the job.
> 		Make a hidden include in one of the standard includes
>
> 	-	Use POSIX names instead of inofficial names. This
> 		would e.g. mean:
>
> 		Include<limits.h>  instead of<sys/limits.h>
>    
This is probably possible and useful. I'll try to change this. Besides, 
I have further changes and fixes, which are not yet in the Perforce depot.
> 	There may be a need fpr some other similar small changes.
>
> Would this be possible? If yes, we could arrange 100% shared identical code.
>    
Probably not 100% identical code because of our style(9) requirements 
but 95% identical code. :) Or we could make a public repository 
somewhere (github, etc.), make a "vendor" branch with code that is 
accepted by both of us and then fork our OS-specific branch. That way 
one could push back improvements to the vendor tree after discussing the 
particular changes and the other party might pull that to his 
OS-specific repository.
> Our problem is that we don't know when this will compatibility is reached.
>    
Compatibility is always a difficult point. After working on 
GNU-compatible grep, GNU-compatible sort, GNU-compatible iconv, I'm 
getting tired of supporting idiotic non-standard decisions and some of 
them are not very easy to implement. But current FreeBSD iconv has a 
good level of GNU-compatibility, so if GNU does fine on Solaris, 
probably this will do fine, as well.

Gabor