On Monday 03 January 2011, Kaspar Brand wrote: > On 03.01.2011 19:21, Eric Covener wrote: > >> on EBCDIC platforms, ap_xlate_proto_from_ascii simply does > >> nothing (it calls apr_xlate_conv_buffer, which returns > >> APR_ENOTIMPL, even in current versions of APR-util, IIMN). > > > > For EBCDIC you're being mislead by the !APR_HAS_XLATE half of > > xlate.c -- it's not a no-op. > > Ah, right - my mistake. But even on an EBCDIC platform, > ap_xlate_proto_from_ascii would only make sense if we were > converting pure 8-bit character strings (from ISO-8859-1 to some > EBCDC code page), right?
ap_xlate_proto_from_ascii() does the right thing for DN strings that contain only ASCII characters. For non-ASCII characters it produces broken results, but that would not be a regression. Therefore we should leave the ap_xlate_proto_from_ascii() call there. Maybe someone familiar with EBCDIC can write an improved conversion function (maybe just escape all high-bit characters?). But I don't see that as a showstopper.
