Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 8, 2016 at 11:24 AM, Eric Covener wrote: > On Mon, Aug 8, 2016 at 12:03 PM, William A Rowe Jr > wrote: > > Easier is to do a compile time comparison of '\n' to 0x15 vs 0x25. But I > > need to know the mystery of 0x25's value through iconv on

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 8, 2016 at 12:03 PM, William A Rowe Jr wrote: > Easier is to do a compile time comparison of '\n' to 0x15 vs 0x25. But I > need to know the mystery of 0x25's value through iconv on your architecture. > Please research, if they simply trade places we are fine. If

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Aug 5, 2016 4:37 PM, "Eric Covener" wrote: > > On Fri, Aug 5, 2016 at 4:58 PM, William A Rowe Jr wrote: > > On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr > > wrote: > >> > >> On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Fri, Aug 5, 2016 at 4:58 PM, William A Rowe Jr wrote: > On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr > wrote: >> >> On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener wrote: >>> >>> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 2:33 PM, William A Rowe Jr wrote: > On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener wrote: > >> On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr >> wrote: >> > We have a few choices, but the bottom line is that

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 4:29 PM, Yann Ylavic wrote: > On Thu, Aug 4, 2016 at 11:10 PM, William A Rowe Jr > wrote: > > On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic > wrote: > >> > >> On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 11:10 PM, William A Rowe Jr wrote: > On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic wrote: >> >> On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr >> wrote: >> > >> > It seems correcting the table is the correct

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 3:52 PM, Yann Ylavic wrote: > On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr > wrote: > > > > It seems correcting the table is the correct way to go, by direct > > observation, and placing great faith that other than

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 9:33 PM, William A Rowe Jr wrote: > > It seems correcting the table is the correct way to go, by direct > observation, and placing great faith that other than 0x15/0x37, > the discrepancies between ASCII <> EBCDIC C0 mappings do > not vary widely

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 2:54 PM, Eric Covener wrote: > On Thu, Aug 4, 2016 at 3:33 PM, William A Rowe Jr > wrote: > > It seems correcting the table is the correct way to go, by direct > > observation > > #error if it's not the EBCDIC platform we made the

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 3:33 PM, William A Rowe Jr wrote: > It seems correcting the table is the correct way to go, by direct > observation #error if it's not the EBCDIC platform we made the observation on? I don't know how much of a technicality another EBCDIC platform

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Thu, Aug 4, 2016 at 2:01 PM, Eric Covener wrote: > On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr > wrote: > > We have a few choices, but the bottom line is that we treat /r/n > > as 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping. > > > >

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 1, 2016 at 3:22 PM, William A Rowe Jr wrote: > We have a few choices, but the bottom line is that we treat /r/n > as 0x0a 0x15 on ebcdic, and perhaps fix our iconv mapping. > > Choice 1; map both 0x15 and 0x37 to ASCII 0x0d, which grows the > number of ascii

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 1, 2016 at 2:08 PM, Eric Covener wrote: > The mainframe guys say it's an unfortunate but intentional > working-as-designed fudge of the iconv results to make the preferred > line separator (0x15)map to/from 0x0A. Seems like safest would be to > not use a table for

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

The mainframe guys say it's an unfortunate but intentional working-as-designed fudge of the iconv results to make the preferred line separator (0x15)map to/from 0x0A. Seems like safest would be to not use a table for conversion but instead go through the same iconv that we're using to convert the

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 1, 2016 at 12:41 PM, Eric Covener wrote: > Looks like iconv on z/os changes behavior when stdout is a terminal, > so that taints some of my observations. Will revisit soon. This bit is a false alarm.

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

Looks like iconv on z/os changes behavior when stdout is a terminal, so that taints some of my observations. Will revisit soon. On Mon, Aug 1, 2016 at 12:28 PM, Eric Covener wrote: > I've sent a note to the z/OS Unix mailing list in hopes someone can > distill the confusing

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

I've sent a note to the z/OS Unix mailing list in hopes someone can distill the confusing over how 0x15 and 0x25 EBCDIC seem to be interpreted differently. 0x15 is kind of weird but 0x25 is hard to justify. On Mon, Aug 1, 2016 at 12:15 PM, Eric Covener wrote: > On Mon, Aug

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 1, 2016 at 11:55 AM, Eric Covener wrote: > I notice ebcdic-us.c in apr-iconv has this mapping instead of 0x85 iconv on linux acts like the apr-iconv table, though.

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Mon, Aug 1, 2016 at 11:28 AM, William A Rowe Jr wrote: > On Sun, Jul 31, 2016 at 11:51 AM, Eric Covener wrote: >> >> On Sun, Jul 31, 2016 at 12:19 PM, William A Rowe Jr >> wrote: >> > Not a conclusion, but this is obviously a

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sun, Jul 31, 2016 at 11:51 AM, Eric Covener wrote: > On Sun, Jul 31, 2016 at 12:19 PM, William A Rowe Jr > wrote: > > Not a conclusion, but this is obviously a bigger headache... > > > > >

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sun, Jul 31, 2016 at 12:19 PM, William A Rowe Jr wrote: > Not a conclusion, but this is obviously a bigger headache... > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ioea600/smbadap021003899.htm I don't think this is an issue for httpd.

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Jul 30, 2016 6:25 PM, "William A Rowe Jr" wrote: > > CR LF are 0D 37 in EBCDIC. Those have protocol specific meanings. > > NL in EBCDIC or ASCII has no specific meaning, it is opaque text. It's not an HTTP CTRL char. > > However, wouldn't we need to escape it in a shell

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

CR LF are 0D 37 in EBCDIC. Those have protocol specific meanings. NL in EBCDIC or ASCII has no specific meaning, it is opaque text. It's not an HTTP CTRL char. However, wouldn't we need to escape it in a shell cmd? We might want to consider escaping many C1 ctrls in the shell. On Jul 30, 2016

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 7:28 PM, Eric Covener wrote: > On Sat, Jul 30, 2016 at 1:11 PM, Yann Ylavic wrote: >> But I mean we pre-suppose in gen_test_char that for T_HTTP_TOKEN_STOP >> and T_HTTP_CTRLS, TEST_CHAR (in util.c) will be called with ascii >>

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Jul 30, 2016 10:15 AM, "Yann Ylavic" wrote: > > On Sat, Jul 30, 2016 at 12:00 AM, wrote: > > > > Looking for someone with an EBCDIC environment to post the output of > > the test_char.h generated file for verification. > > > [] > > > > +#if

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 1:11 PM, Yann Ylavic wrote: > But I mean we pre-suppose in gen_test_char that for T_HTTP_TOKEN_STOP > and T_HTTP_CTRLS, TEST_CHAR (in util.c) will be called with ascii > bytes (because they come from the network in ap_getline_core(), not > from

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 6:35 PM, Eric Covener wrote: > On Sat, Jul 30, 2016 at 12:28 PM, Yann Ylavic wrote: >> On Sat, Jul 30, 2016 at 5:37 PM, Yann Ylavic wrote: >>> >>> (I'm a bit lost on where are/aren't EBCDIC octets here). >>

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 12:28 PM, Yann Ylavic wrote: > On Sat, Jul 30, 2016 at 5:37 PM, Yann Ylavic wrote: >> >> (I'm a bit lost on where are/aren't EBCDIC octets here). > > Mostly, I understand that T_HTTP_TOKEN_STOP and T_HTTP_CTRLS should be > used

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 5:37 PM, Yann Ylavic wrote: > > (I'm a bit lost on where are/aren't EBCDIC octets here). Mostly, I understand that T_HTTP_TOKEN_STOP and T_HTTP_CTRLS should be used with ascii chars because they come from test_isascii_equiv() (and due to the fact

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 11:37 AM, Yann Ylavic wrote: > Or, if that's needed (for all "ctype" functions), why don't we: > ap_xlate_proto_from_ascii(, 1); > at the very beginning of each loop and be done with it? > > Is it because we are mixing quoted string literals

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Jul 30, 2016 9:41 AM, "Jim Jagielski" wrote: > > If we use this table more than once and we depend on consistency > between them then we should make it a shared extern. Therein lies the rub... For this particular case, requiring crossplat compilation and execution,

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 5:15 PM, Yann Ylavic wrote: > On Sat, Jul 30, 2016 at 12:00 AM, wrote: >> >> Looking for someone with an EBCDIC environment to post the output of >> the test_char.h generated file for verification. >> > [] >> >> +#if

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

On Sat, Jul 30, 2016 at 12:00 AM, 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

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

If we use this table more than once and we depend on consistency between them then we should make it a shared extern. > On Jul 29, 2016, at 6:00 PM, wr...@apache.org wrote: > > Author: wrowe > Date: Fri Jul 29 22:00:52 2016 > New Revision: 1754579 > > URL:

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

What's going on with 0x15 (newline in ebcdic)? It is a control char that we map to 0x85 but it doesn't look right int he generated table. On Fri, Jul 29, 2016 at 9:37 PM, Eric Covener wrote: > from rev below: > http://people.apache.org/~covener/test_char.h > > > > On Fri, Jul

Re: svn commit: r1754579 - /httpd/httpd/trunk/server/gen_test_char.c

from rev below: http://people.apache.org/~covener/test_char.h On Fri, Jul 29, 2016 at 6:00 PM, wrote: > Author: wrowe > Date: Fri Jul 29 22:00:52 2016 > New Revision: 1754579 > > URL: http://svn.apache.org/viewvc?rev=1754579=rev > Log: > Replacement solution to identify