Re: Calling iconv() with the correct prototype definitions

All,

 

This has been a VERY good thread for me.

 

Scott, you're right, I'm not a c programmer [does it show? :-)]. I'm
embarrassed to say that, although I regularly code in java I missed the
casting implied in the (size_t)-1 return value. 

 

[Scott wrote:

The phrase "(size_t)-1" is not decrementing size_t by 1.  It is casting
-1 to a size_t type.  (If you're not a C programmer, you probably have no
idea what I meant by that.)]

 

The good news is that I've got my CCSID conversion from 37 to 1208 working
on my open(). Even better is that I've now got a working example of iconv()
[thanks Scott, I'll have a good tinker with that soon. The problem, as
always, is finding a use for my new toy.].

 

My original problem was caused by three errors:

1)       At work we use copysrc containing the open(), close(), read() and
write() prototype definitions, oflag values and mode values. Some of this is
wrong.

2)       The examples of open() I found by trawling our own source files
were poorly designed, but worked in their limited capacity.

3)       I assumed that the copysrc I included was correct and the examples
I found worked. NEVER AGAIN!

 

After Scott's heads-up over the casting I thought I'd better print off the
open() documentation and read it VERY carefully. I then looked at our
copysrc and open() examples and I realised where my problem lay: All the
examples I found at work used O_CODEPAGE (O_CCSID wasn't even defined -
subject of a previous thread). Also, as the copysrc was created before the
optional fifth parameter was introduced they opened the file, creating it
with the file CCSID. The file was then closed and re-opened. Unfortunately,
the second open was performed passing only the first two parms (with
O_TEXTDATA set on in oflag). Thus, the open CCSID was not set. So, I  simply
added the third (mode) and fourth (Conversion ID) parameters, specifying 0
(zero) as the open CCSID it all worked. I now have my xml in UTF-8 format,
and it was really easy to do!!!

 

I tried some really unusual characters so I could have a good look at the
hex values to make sure I wasn't simply creating ASCII data - it all looks
great, even my java parser was happy parsing these characters.

 

Thanks everyone for your wise words.

 

Larry