[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Character conversion



To elaborate: "common source" in this case means "common origin."

Also, it occurs to me that I didn't point out the real problem here.  In
this case, toASCIIF contains the following statement:

return iconv(wkDsFileASC: %addr(p_buffer): peBufSize
                        : %addr(p_buffer): peBufSize) ;

Note that peBufSize in this case is the amount of data in the buffer, rather
than buffer size.  Say we have 16 bytes in.  Now iconv thinks we have a
16-byte output buffer.  Fine, it will write as many characters as it can to
the output (which is not enough in a SBCS->DBCS translation), and will be
forced to stop early.  All is successful as far as that goes, so it will
return with zero, and the fact that the whole of the input was not processed
is ignored. 

Maybe I'm wrong, though.  How do _you_ say this will function?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I find that a great part of the information I have was acquired by looking
up something and finding something else on the way."
        -- Franklin P. Adams 

> -----Original Message-----
> From: Dennis Lovelady [mailto:iseries@xxxxxxxxxxxx]
> Sent: Monday, November 15, 2010 1:36 PM
> To: 'HTTPAPI and FTPAPI Projects'
> Subject: RE: Character conversion
> 
> It might be a little more helpful, Scott, if I understood which part of
> my statement raised your ire.  For now I will just assume that you're
> objecting to the comment about the routines being similar.  I had no
> basis for that other than common source.  But it was stated as "very
> likely" rather than any informed position.
> 
> If, on the other hand, you are objecting to the fact that FTPAPI
> doesn't properly handle SBCS -> DBCS conversions, all I can say is that
> the version I have been working with does not.  Since the only return
> value from the conversion routines is negative for error / positive for
> success, wrong amounts of data will be processed/written after
> translation.  As an example (from the if_read procedure, free-form for
> clarity) :
> 
> wwRC = read(peFileDes: %addr(peBuffer): peBufLen) ;   // wwRC = bytes
> read
> if wwrc > 0 and wkBinary = *Off ;
>    toAsciiF(peBuffer: wwRC) ;             // Convert to remote CCSID
> fi
> return wwRC ;
> 
> Now, if toAsciiF causes a conversion from SBCS to DBCS, what do you
> expect the caller of this routine will see?  It has no idea what length
> iconv() has determined as appropriate after conversion.
> 
> Dennis Lovelady
> http://www.linkedin.com/in/dennislovelady
> --
> "I find television very educating. Every time somebody turns on the set
> I go into the other room and read a book."
>         -- Groucho Marx
> 
> > -----Original Message-----
> > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> > bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
> > Sent: Monday, November 15, 2010 12:35 PM
> > To: HTTPAPI and FTPAPI Projects
> > Subject: Re: Character conversion
> >
> > Codswallop.
> >
> > On 11/15/2010 8:05 AM, Dennis Lovelady wrote:
> > > Well, before you sign in to that insane asylum, I concur that your
> > second
> > > point looks like a problem, and may (?) be the source of the first
> > issue.
> > > While I haven't used HTTPAPI, and haven't seen the issue you
> mention,
> > I did
> > > see this as a potential issue in FTPAPI, and am working to correct
> it.
> > Very
> > > likely the routines look very similar to one another.  (Or did.)
> > ---------------------------------------------------------------------
> --
> > This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> > ---------------------------------------------------------------------
> --

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------