Re: Character conversion

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

(With exaggerated patience.) Yes, you are absolutely right.

However, HTTPAPI does not call that routine when translating a user's 
data as it's sending it out.  It calls a routine that allocates dynamic 
memory, and extends the memory as needed to handle up to 16MB of output 
data if the translation requires it.

HTTPAPI does not, however, use that routine throughout because it's less 
efficient than reusing the same memory buffer, and for much of the HTTP 
protocol, it's unnecessary.

You may have noticed that FTPAPI has two translation routines (both are 
wrong.)  ToASCII and ToASCIIF.  The idea is that the _file_ data might 
be translated to a different CCSID than the actual FTP protocol 
requires, so it has two separate routines.

HTTPAPI has the same thing -- but the routine for _user_data_ ("file 
data") doesn't have the problem that FTPAPI has.  It expands the memory 
buffer as needed.

Only the routine for _protocol_ data has the problem you describe -- and 
I can't see why Kaj Julius would be using that routine.  So either 
there's a bug, as you say, in which case I need to know _where_ that bug 
is, and how to reproduce it.

Or there's no bug, and Kaj is manually calling the routine to convert to 
ASCII, but has picked the wrong routine.

So I need input from Kaj as to what he's doing.

You & I bickering is pointless... especially since we seem to be on 
completely different topics.  I'm talking about helping Kaj with 
HTTPAPI, and you seem to be insisting that FTPAPI is wrong (as if that 
somehow proves that HTTPAPI is also wrong)  Please... this is taking up 
my time.  FTPAPI is wrong, no question about it... can we move on to 
helping Kaj instead of dwelling on it?


On 11/15/2010 12:49 PM, Dennis Lovelady wrote:
> 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?
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------