"Keith Thompson" <Keith.S.Thompson+
u@gmail.com> wrote in message
news:871pyxljfc.fsf@nosuchdomain.example.com..."Paul Edwards" <mutazilah@gmail.com> writes:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:875xo9ln93.fsf@nosuchdomain.example.com...
>
True, but I don't know of anyone who's interested in a C 90 compiler
with this kind of extension. Paul Edwards has made it clear he's only
interested in unextended C90, and anyone else can just use a more
modern
compiler.
>
While not a "compiler" per se, there is one extension to
C90 I might add, which is to have formal names like:
>
ESC_CHAR '\x1b'
ESC_CHAR_STR "\x1b"
>
that would allow me to support ASCII and EBCDIC in
my "starter suite".
>
I don't see why this needs to be a language extension. Just define it
as a macro wherever it's needed.
Because it is something I expect from the language - a portable
way to provide the keys required to drive an ANSI X3.64 terminal.
Microemacs and msged need them.
>
Do they?
How else do you propose providing a fullscreen interface?
We have a standard - ANSI X3.64.
I probably need names for the control keys too for microemacs.
>
I'll need to revisit the code to be sure.
>
My guess is that getting microemacs and/or msged to work with EBCDIC is
going to involve more than just defining the Escape character.
microemacs has been working on EBCDIC for years. I ported
it already (to a sufficient extent, anyway).
For example, here's a code fragment from msged :
>
while ((ch != 'a') && (ch != 'r')) {
ch = 0x7f & getkey();
ch = tolower(ch);
if (ch == 0x1b)
return(NULL);
}
I haven't attempted to do msged yet. But yes, that's exactly
the sort of code that I want to eliminate. Although that
particular bit of code isn't in the msged version I am using:
D:\devel\msged\src>grep -i 7f *
fido.c: tms.tm_year = (x & 0x7f) + 80;
keys.h: #define Key_C_BS 0x007f
keys.h: #define Key_A_8 0x7f00
spawn.asm: xfcb2 db 16 dup(?) ; 70..7F - default FCB
D:\devel\msged\src>
I can't remember if I previously eliminated it myself, but if I did,
it must have been in the 1990s, because I see no change involving
a 7f from my oldest available release from the 1990s.
But yes - that's the whole point - I expect to be able to write
that code portably, in either the standard, or a modified
standard - whatever is required to get ANSI X3.159-1989
to support ANSI X3.64.
It could be an ANSI X3.64 extension I suppose.
0x1b is the ASCII code for the Escape character. Defining a macro
*within the code* is nearly trivial;
Defining it in a standard C90 header file or some extension
is equally as trivial, and would put it where it belongs, rather
than in every single fullscreen application.
the only tricky part would be
determining whether the current system uses EBCDIC.. But masking the
character value will break on an EBCDIC system, where many printable
characters have codes exceeding 0x7f.
And a C90-compliant program *already* shouldn't be doing
such masks, as C90 *already* allows for EBCDIC.
(This is assuming there's any
reason at all to make microemacs and msged support EBCDIC, something I'm
very skeptical about.)
What editor would you like me to use on my mainframe
operating systems (z/PDOS and z/PDOS-generic) instead?
edlin?
I was using microemacs today on z/PDOS-generic to modify
my makefile.zpg in PDPCLIB, as I am now able to run the
entire toolchain to produce an executable. Actually I could
already do that previously, but now I can use standard
HLASM in the process.
If you insist on using a language extension to support the Escape
character, you could just copy gcc's '\e'.
That puts a burden on the compiler - every compiler,
basically - which is far from the trivial addition to an
existing header file, or a new header file, that I
suggested as an alternative.
BTW, the subject says 80386 C compiler, but I am likely
going to do S/370 (which also runs on z/Arch) at the same
time, as I realized that circumstances have changed such
that I can have a public domain suite for the mainframe
too if the compiler is covered. A bit of work would be
required to z/PDOS-generic to support the IFOX
MVS executables to cover the assembler. Unfortunately
the assembler is written in assembler instead of C (for
obvious historical reasons), but it's still public domain.
BFN. Paul.