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

RE: Character conversion



Scott, I apologize for implying that HTTPAPI and FTPAPI have anything to do
with one another.  It was an unsupportable supposition.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I get my exercise acting as a pallbearer to my friends who exercise."
        -- Chauncey Depew 



> (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
> -----------------------------------------------------------------------

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