Re: Anybody working on ISO/IEC 15435 (i18n.h)?

[Keld Jørn Simonsen <keld@xxxxxxxx>]

On Thu, Feb 03, 2000 at 07:41:00PM +0200, Kai Henningsen wrote:
> keld@xxxxxxxx (Keld J¢rn Simonsen)  wrote on 03.02.00 in <20000203161346.A4914@xxxxxxxxxxxxxx>:
> 
> > On Mon, Jan 31, 2000 at 08:25:00PM +0200, Kai Henningsen wrote:
> 
> > > - stringn?copy is stringn?cpy in the C bindings. All other names are
> > > identical.
> >
> > Is that a problem?
> 
> Well, it's a difference without any explanation. One wonders if it was  
> even intentional.

OK, I see what you mean. The difference is not intentional
(ie: it is an error.
I thought it was a problem that the names were the same.

> > > - there are a number of types that are translated as structs. This is
> > > probably a bad idea; all of them are allocated, manipulated, and freed by
> > > the library, so they probably ought to be opaque pointers (like FILE *).
> >
> > Maybe. It is a matter of style. The idea was that the library
> > would handle the required operations to deal with the object.
> > We also need to think of binding to other languages, such as
> > Fortran, Cobol, lisp, prolog and APL.
> 
> An opaque pointer should work with just about anything. No problems with  
> structure passing conventions, either.

This is what is known in X/Open circles as m-star functions.
> 
> > Is this C or C++, or both?
> 
> I'm not a C++ person.
> 
> > > I'm interested in implementing at least part of this, if we can clear up
> > > the interface problems.
> >
> > Very good! Are you coperating with Uli?
> 
> Do you mean Ulrich Drepper? Not so far. Is he working on something  
> similar?

I talked with him some time ago. I am not sure what he is up to.

> Anyway, whatever I do would be under a free enough license, though I'll  
> probably not spend much thought on details until there is something with  
> enough substance so others would actually be interested in having it :-)

Good!
> 
> 
> Problem is, we do not even know wchar_t is UCS-4 (or UTF-16). Hmm. Not so  
> good. I'll have to think about that a little longer.

The string type can take the repertoire of the full UCS.

Keld
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/