httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c
Date Sat, 30 Jul 2016 15:37:32 GMT
On Sat, Jul 30, 2016 at 5:15 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Sat, Jul 30, 2016 at 12:00 AM,  <wrowe@apache.org> wrote:
>>
>> Looking for someone with an EBCDIC environment to post the output of
>> the test_char.h generated file for verification.
>>
> []
>>
>> +#if APR_CHARSET_EBCDIC
>> +/* See util.c for complete explanation of this table */
>> +static const short ucharmap[] = {
>
> We already have:
> #if APR_CHARSET_EBCDIC || defined(isascii)
> #define apr_isascii(c) (isascii(((unsigned char)(c))))
> #else
> #define apr_isascii(c) (((c) & ~0x7f)==0)
> #endif
>
> so why is this charmap needed?
> Doesn't APR (via EBCDIC-system libc's isascii) take care of it already?
> It seems EBCDIC has never been handled here before, yet APR "ctype"
> functions have always been used. What's special with isascii()?

Or, if that's needed (for all "ctype" functions), why don't we:
        ap_xlate_proto_from_ascii(&c, 1);
at the very beginning of each loop and be done with it?

Is it because we are mixing quoted string literals (natively EBCDIC)
and char comparisons?

(I'm a bit lost on where are/aren't EBCDIC octets here).

Mime
View raw message