Hi Thorsten,
On Wed, 2017 May 3 15:57+, Thorsten Glaser wrote:
> Dixi quod…
>
> >Use U+4DC0 HEXAGRAM FOR THE CREATIVE HEAVEN (䷀) then ☺
>
> I *do* have a follow-up question for that now.
>
> The utf8bug-1 test fails because its output is interpreted as UTF-8,
> but the UTF-8 string it
Daniel Richard G. dixit:
>Good news!
>
>I played with this some more, and found what was missing: a call to
>setlocale().
Oh.
>/* very much NOT Latin-1 compatible */
>setlocale(LC_ALL, "Ru_RU.IBM-1025");
[...]
>...the input should have been converted to ISO 8859-5.
>
>So it seems like
Daniel Richard G. dixit:
>On Tue, 2017 Apr 25 10:59+, Thorsten Glaser wrote:
>> Well, the hand-edited tables would be known to be stable and
>> (somewhat) correct, but…
>>
>> >Even if you really do need a table, you could populate it on startup
>> >using these.
>>
>> I guess I can probably
On Tue, 2017 Apr 25 10:59+, Thorsten Glaser wrote:
> Well, the hand-edited tables would be known to be stable and
> (somewhat) correct, but…
>
> >Even if you really do need a table, you could populate it on startup
> >using these.
>
> I guess I can probably work with that.
>
> So we’re up
Daniel Richard G. dixit:
>It wouldn't work to do the EBCDIC->ASCII conversion all at runtime? z/OS
>does provide functions for this, and these will adjust to whatever the
>current EBCDIC codepage is:
>
>etoa():
>
>
On Sat, 2017 Apr 22 23:26+, Thorsten Glaser wrote:
>
> >Oh, so you mean like if(c=='[') and such? That is certainly
> >reasonable. The program would be tied to the compile-time codepage no
> >worse than most other programs.
>
> Right. So either something like -DMKSH_EBCDIC_CP=1047 or limiting
Hi Daniel,
>Hi Thorsten, apologies for the delay.
don’t worry about that ;)
>> >Interesting! So POSIX assumes ASCII, to a certain extent.
>>
>> Yes, it does. I think EBCDIC as charset is actually nonconformant, but
>> it probably pays off to stay close nevertheless. (This is actually
>> about
Hi Thorsten, apologies for the delay.
On Thu, 2017 Apr 20 21:49+, Thorsten Glaser wrote:
>
> >Interesting! So POSIX assumes ASCII, to a certain extent.
>
> Yes, it does. I think EBCDIC as charset is actually nonconformant, but
> it probably pays off to stay close nevertheless. (This is
Hi,
remember me? ;-)
I’m writing because I was pondering EBCDIC for an upcoming change.
Daniel Richard G. dixit:
>I don't think there would be any instance where the code needs to know
>"I am building for EBCDIC 1047" vs. "for EBCDIC 037" or whatnot. The
>transcoding of char/string literals
On Wed, 2015 May 6 20:22+, Thorsten Glaser wrote:
Daniel Richard G. dixit:
Unless we convert EBCDIC to Unicode ourselves (as opposed to letting
the system do it; I’m currently convinced that we really want to do
this actually, since we don’t support them all anyway).
If you bundle a set
Hi again,
a few questions back, and a few early comments on the general
idea (I’ve not yet had the time to look at the patch itself):
Assume we have mksh running on your EBCDIC environment. Let me
ask a few questions about this sort of environment, coupled with
my guesses about it.
- the
On Fri, 2015 Apr 24 14:29+, Thorsten Glaser wrote:
Woah!
I’m amazed, flattered, impressed, puzzled, wondering, etc. at the same
time. Please give me a bit to come up with a suitable reply, this
deserves some time to think about, and I love your enthusiasm.
Oh, you're very kind!
mksh
Hello list,
I'd like to submit some changes that add support for IBM z/OS mainframe
systems (specifically, for mksh running in the OMVS Unix environment),
including compatibility with EBCDIC.
The test suite tallies up as follows in an EBCDIC run:
Total failed: 52 (4 ignored) (48 unexpected)
13 matches
Mail list logo
