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