This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch: configure -vs- iconv

Ugh. Sorry about not cc'ing this to the correct list.

> Benjamin> FYI libstdc++-v3 is using iconv too. Our autoconf/automake
> Benjamin> macros are a bit more out of control....
> Benjamin> you might want to check for iconv_open, iconv_close too.
> Are there systems where iconv() exists but these do not?  I admit I am
> not fully aware of the portability limitations of iconv().  I've just
> made it so that it if iconv() exists then we will try to use it.  I do
> pretty much the same thing in libgcj.

now that i look at never check for iconv.h.... you'll definitely 
need to do this........

anyway. I ask about this because it looks like the signatures change 
between glibc2.1.x and glibc2.2 (or between RH 6.2 and RH 7.0, in 
particular.) The RH 7 signatures are correct.

Are you adding checks for this? 

       size_t iconv (iconv_t cd,
                     const char* * inbuf, size_t * inbytesleft,
                     char* * outbuf, size_t * outbytesleft);

       size_t iconv (iconv_t cd,
                     char* * inbuf, size_t * inbytesleft,
                     char* * outbuf, size_t * outbytesleft);

If so, can I use them too?

I don't know if iconv exists w/o iconv_open, iconv_close. I dunno, since 
libstdc++-v3 gets nailed for everything it doesn't check for at configure 
time, I just went ahead and did these checks too....

> Benjamin> Just out of curiosity, do you have docs on your usage of
> Benjamin> iconv? (we talked about this a long time ago). Or, do you
> Benjamin> have more (new) code that uses iconv that you could point me
> Benjamin> at?
> There aren't docs on our usage of iconv.  gcj is pretty light on
> documentation overall :-(.  AG keeps threatening to check in gcj.texi,
> but fortunately that hasn't happened yet...
> For the runtime, what we do is fall back to trying iconv if no
> built-in charset conversion class exists.

by "built-in charset conversion class" you mean the stuff based on ISO 
C9X, ie wmemcmp, et al? (This seems unlikely)

Or, what?

> For gcj, we use iconv if it exists.  If not we assume all source files
> are UTF-8 encoded.  Our job here for Java is relatively simple because
> the compiler internally always uses UTF-8 (so one of the parameters to
> iconv_open is fixed) and because we know the runtime character set is
> always UCS-2.

Kay. (You are using UCS-2 instead of UNICODE for iconv_open?)

I'll add UCS-2 <-> UTF8 bits in the libstdc++-v3 testsuite.

> I've been meaning to ask you how UCNs work in C++.  Is there an online
> document I can read?  In particular my problem is this: we can use the
> `gcjh' tool to generate a C++ header from a Java class file.  However,
> in Java identifiers can have non-ASCII characters in them.  How can I
> represent these characters in the C++ header?  In particular I want to
> represent them such that the Java and C++ name manglings will agree.

No. The codecvt wrapper for iconv is documented, but that's about it.

Jason had some thoughts about this, and posted them to in 
either this month or last. I believe someone else has taken up the work 
now -- see Neil Booth's

I believe this work is still in progress.....

> Benjamin> I just recently got this working for libstdc++-v3. Part of
> Benjamin> this was testing with unicode arrays, with the specific
> Benjamin> intention of making some kind of UCS2 translation capability
> Benjamin> for the c++ library. (With being able to play nice with Java
> Benjamin> WRT wide strings a particular requirement.) Any thoughts on
> Benjamin> how I can test this?
> You could write a Java program that has a native (C++) method, and
> then you could get a pointer to the underlying (java-)character array
> in the native method and do weird C++ things to it.

Hmm. Ok.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]