Re: RFC: IDN support in getaddrinfo().

[Simon Josefsson <jas at extundo dot com>]

Ulrich Drepper <drepper@redhat.com> writes:

>> Do you have any opinion on the format of the external files?  Text or
>> binary?  Platform dependent or independent binary?  Export both
>> Unicode NFKC and RFC 3454 tables, or just one of them?
>
> Definitely binary data.  During the glibc build a program can be
> constructed (or better yet, make it a script) which construct the binary
> data file.  It's probably best to make it a DSO which symbol has no
> function symbol (just the data symbols).
>
>
>> This will likely take some time to implement, the tables are exported
>> to several closely intertwined C variables, and they are accessed from
>> many functions.
>
> If you do it as a DSO there shouldn't be too much change.  When opening,
> assign the variable addresses in the DSO to global variables.

I'm a little confused, earlier you said to use read, but I don't know
how `read' could be used on a DSO to get something useful out of it.
Should I create a DSO and use dlopen on it?  It was quite some time
since I last used dlopen, but I'll see if I can get it to work...

[Licenses]
> No problem.

I'm not sure the list was conclusive, but it should be obvious once I
send the actual patch.

The approach I'm considering is to take the current libc libidn
"add-on" package but change the Versions file so it only export the
necessary APIs in a GLIBC_PRIVATE block.  Any problems with this?  The
alternative approach I see is to move everything into sysdeps/posix
(or somewhere), but that doesn't seem as clean.

I'm building libc CVS now, perhaps I'll be able to send an early
version of the patch later tonight.

Thanks,
Simon