On Fri, 2016 Aug 19 12:28-0700, Paul Eggert wrote:
> Thanks, I installed those changes in your name, after reformatting the
> ChangeLog file and commit message to fit Gnulib style. You can see
> what that format is like by doing "git pull; git format-patch --stdout
> -1": the ChangeLog entry's cont
Thanks, I installed those changes in your name, after reformatting the ChangeLog
file and commit message to fit Gnulib style. You can see what that format is
like by doing "git pull; git format-patch --stdout -1": the ChangeLog entry's
contents duplicate the commit message, except that they're i
Daniel Richard G. wrote:
> The second change, to test-sigpipe.sh, fixes what looked like a typo.
> (A goes with A, B goes with B, so what should go with C...)
Thanks. This change is definitely good.
Bruno
On Thu, 2016 Aug 18 01:53-0700, Paul Eggert wrote:
>
> Hmm, sorry, I don't seem to have them. Could you please resend them,
> in 'git format-patch' format? Thanks.
They are attached. I needed to make some minor edits on the format-patch
output, hopefully harmless. The ChangeLog-style entries are a
Daniel Richard G. wrote:
(Did you get the minor changes to test-c-strncasecmp.c and
test-sigpipe.sh? Those are the only salient ones still outstanding)
Hmm, sorry, I don't seem to have them. Could you please resend them, in 'git
format-patch' format? Thanks.
On Wed, 2016 Aug 17 17:47-0700, Paul Eggert wrote:
>
> Thanks, I finally installed those into the main repository on
> Savannah. I had to write ChangeLog entries, which I took from your
> email. I also fixed a couple of minor glitches that I noticed.
Much appreciated, Paul.
(Did you get the minor
Daniel Richard G. wrote:
Okay, I've split my changes into a set of patches, attached. These
patches are orthogonal and may be applied in any order:
Thanks, I finally installed those into the main repository on Savannah. I had to
write ChangeLog entries, which I took from your email. I also fix
Okay, I've split my changes into a set of patches, attached. These
patches are orthogonal and may be applied in any order:
gnulib-zos-ascii.patch: When in a non-ASCII environment, disable tests
that assume ASCII.
gnulib-zos-charset.patch: Added appropriately conditional #pragmas so
that the test
On Sat, 2015 Sep 26 23:59-0700, Paul Eggert wrote:
>
> Given all the problems mentioned (including some in the proposed
> patches), let's give up on trying to support any such folks. If they
> want to build gnulib-using software on z/OS, they'll have to build
> with the default configuration in wh
Daniel Richard G. wrote:
It's certainly not the default, but given the sort of history and
longevity that surround many mainframe installations, I wouldn't
be surprised if some folks do.
Given all the problems mentioned (including some in the proposed patches), let's
give up on trying to suppo
On Sat, 2015 Sep 26 09:08-0700, Ben Pfaff wrote:
>
> A "char" configured as signed in EBCDIC violates the ANSI C standard,
> which says:
>
> If a member of the basic execution character set is stored in a
> char object, its value is guaranteed to be positive.
Now _that's_ a welcome bit
On Sat, Sep 26, 2015 at 12:39:52AM -0400, Daniel Richard G. wrote:
> I'm happy to report that test-c-ctype in Git ff1ef114 now passes with
> both signed and unsigned EBCDIC chars on z/OS. Thank you for chasing
> this down!
A "char" configured as signed in EBCDIC violates the ANSI C standard,
which
On Fri, 2015 Sep 25 19:49-0700, Paul Eggert wrote:
>
> Thanks, given all that history let's rewrite it so that the compiler
> can decide what '\n' maps to, that way it'll work even in EBCDIC
> environments that agree with IANA instead of IBM. I installed the
> attached patch, which should fix the
Daniel Richard G. wrote:
So to make a long story short: After I add \x15 and remove \x25 to/from
_C_CTYPE_CNTRL for EBCDIC, the test passes in the signed-char case.
Thanks, given all that history let's rewrite it so that the compiler can decide
what '\n' maps to, that way it'll work even in EB
Hi Paul,
On Fri, 2015 Sep 25 00:29-0700, Paul Eggert wrote:
> Thanks for checking it. On further thought, I'd rather that we went
> to inline functions, as that would have made ironing out all these
> glitches easier, and anyway inline functions are typically the way to
> go for this sort of thin
Thanks for checking it. On further thought, I'd rather that we went to inline
functions, as that would have made ironing out all these glitches easier, and
anyway inline functions are typically the way to go for this sort of thing
nowadays. I installed a further patch to do that (see URL below
Hi Paul,
I tested your changes in git a406de9c. A handful of fixes are needed:
* c_isascii(): Add \x07 (DEL) as an ASCII character.
* c_isascii(): Drop \xFF (EO), as this is not ASCII.
* c_iscntrl(): Add \x07 (DEL) as a control character.
* c_iscntrl(): Drop \xFF (EO), as apparently this is no
On 09/22/2015 11:58 PM, Daniel Richard G. wrote:
What about having a check in test-c-ctype that compares c_iscntrl() with
its system counterpart? If the assumption is that alternate EBCDIC
encodings used with Gnulib will agree with EBCDIC-1047 on these
characters, then that should be checked.
G
On 09/22/2015 11:58 PM, Daniel Richard G. wrote:
There is one
assertion that needs to be #ifdef'ed out for EBCDIC:
Better than that, let's improve the assertion so that it works for
EBCDIC. I installed the attached.
>From a7a072a14945dfbe5fdd207926846b2c286b4b83 Mon Sep 17 00:00:00 2001
From:
Okay, I tested your latest changes (git 4d83e798). There is one
assertion that needs to be #ifdef'ed out for EBCDIC:
$ ./test-c-ctype
/path/to/gltests/test-c-ctype.c:62: assertion 'c_isascii (c) == (c >= 0 &&
c < 0x80)' failed
CEE5207E The signal SIGABRT was received.
ABORT instru
Code that
uses c-ctype wants only ASCII letters, and departing from this would
likely break things.
How would that match occur? c_isalpha() was/is using a "switch"
statement for EBCDIC.
Oh, sorry, I was assuming that the substitution was being proposed for all the
functions; but it's being pr
On Tue, 2015 Sep 22 15:03-0700, Paul Eggert wrote:
> Thanks for explaining. I still see a problem with the proposed patch,
> though, in that (if I'm understanding it correctly) it would cause
> c_isalpha (120) to succeed, even though EBCDIC 120 corresponds to
> U+00CC LATIN CAPITAL LETTER I WITH G
Thanks for explaining. I still see a problem with the proposed patch,
though, in that (if I'm understanding it correctly) it would cause
c_isalpha (120) to succeed, even though EBCDIC 120 corresponds to U+00CC
LATIN CAPITAL LETTER I WITH GRAVE, and that is not supposed to be an
alphabetic char
On Tue, 2015 Sep 22 14:08-0600, Eric Blake wrote:
> On 09/22/2015 02:00 PM, Paul Eggert wrote:
> >>
> >> wc: file "//dev/null": EDC5047I An invalid file name was specified
> >> as a function parameter
> >
> > How about if we add //dev/null to the configure-time test as to
> > whether / and // are t
On Tue, 2015 Sep 22 12:50-0700, Paul Eggert wrote:
> A few non-ctype-related comments:
>
> Omit parens around arguments of 'defined', e.g., say "defined __MVS__"
> not "defined (__MVS__)".
Understood.
> I agree with Eric that we should rename "__string" rather than fiddle
> with #undefing it. I
Hi Paul,
On Tue, 2015 Sep 22 12:32-0700, Paul Eggert wrote:
> Thanks for looking into this. I have some questions about the c-ctype
> changes. It appears that the proposed patch defers to the system
> functions (which use the current locale), but that's not the intent of
> c-ctype: it's supposed
On 09/22/2015 12:27 PM, Daniel Richard G. wrote:
Wouldn't it be easier to apply everything to a feature branch, and
integrate it bit by bit?
You can do that in your own repository if it makes things simpler, but
for something this small I'd rather just see patches via email.
wc: file "//dev/
On 09/22/2015 02:00 PM, Paul Eggert wrote:
>> wc: file "//dev/null": EDC5047I An invalid file name was specified as
>> a function parameter
>
> How about if we add //dev/null to the configure-time test as to whether
> / and // are the same? If //dev/null doesn't work, then / and // are
> not the
Ooops, I forgot to add a dependency. I installed the attached followup
patch.
>From 07ed58f3c5b54fe3935ce522dbc1c1a716185e67 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 22 Sep 2015 12:44:25 -0700
Subject: [PATCH] * modules/c-ctype (Depends-on): Add verify.
---
ChangeLog | 1 +
A few non-ctype-related comments:
Omit parens around arguments of 'defined', e.g., say "defined __MVS__"
not "defined (__MVS__)".
I agree with Eric that we should rename "__string" rather than fiddle
with #undefing it. It's just a placeholder name. I suggest renaming it
to "__str". We can
Thanks for looking into this. I have some questions about the c-ctype
changes. It appears that the proposed patch defers to the system
functions (which use the current locale), but that's not the intent of
c-ctype: it's supposed to correspond to a stripped down POSIX "C" locale
regardless of
Hi Eric,
On Tue, 2015 Sep 22 09:23-0600, Eric Blake wrote:
>
> Thanks for the work. Can you please split the patch into a series of
> multiple pieces, one patch per issue, so that we can apply the obviously-
> correct ones while still discussing the other pieces, rather than
> holding the entire l
On 09/21/2015 08:28 PM, Daniel Richard G. wrote:
> Hello list,
>
> The attached patch, against Git master, addresses numerous
> incompatibilities in Gnulib with IBM z/OS (a mainframe operating system)
> and the EBCDIC encoding.
>
> With my changes, Gnulib builds successfully, and most of the test
Hello list,
The attached patch, against Git master, addresses numerous
incompatibilities in Gnulib with IBM z/OS (a mainframe operating system)
and the EBCDIC encoding.
With my changes, Gnulib builds successfully, and most of the tests
succeed. The remaining failures are as follows.
These appear
34 matches
Mail list logo
