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

[Joerg Schilling]

Gabor Kovesdan <gabor at freebsd.org> wrote:

> > 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.

I did not yet look into this part of the code. I was looking at the Solaris 
implementation and the size of some of the modules on Solaris.

BTW: is there a way to download it as a whole as e.g. a TAR archive?

> > 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.

You could include a module local include file that hides the inclusion of 
<sys/cdefs.h>. It is always better to have such local portability needs 
implemented only once.


> 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.

Does this mean that you believe you are ready for integration from your view?

> > 	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 

>From what I see when looking at BSD code, the main difference between Solaris 
and FreBSD is (FreeBSD is also oriented on the Bill Joy indentation style) that
FreeBSD has logical continuations for long lines at the beginning while Solaris 
likes them at the end of the line before. In general, cstyle(1) flags few lines
from *BSD code while e.g. code from the FSF gets an average of two cstyle(1) 
warnings per code line.

> 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.

Maybe we can even hide the differences in local files included with 
#include "x.h". I see <sys/cdefs.h> (as mentioned already) and I see the need 
to keep /usr/include/iconv.h from Solaris and to put anything FreeBSD has into
an additional local include file.

> > 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.

"GNU compatibility" at iconv level may more be a problem on OpenSolaris as GNU 
iconv (without manually adding aliases) will not recognize many locale names
used by Solaris since the late 1980s even though these names are still 
permitted by the standard.

In many cases, GNU getopt_long() is a problem as GNU getopt_long() is based on 
a design problem that may hit people when there are similar long option names 
where one is a substring of another. Other (even older) long option parsers 
like my getargs() from 1982) don't suffer from this kind of problems. 
Fortunately iconv(1) does not need to have long options....

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily