Re: 80386 C compiler

"Paul Edwards" <mutazilah@gmail.com> writes:

"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.

I don't think that's a reasonable expectation, but it's your project,
so do what you like.

Microemacs and msged need them.

>
Do they?

>
How else do you propose providing a fullscreen interface?
>
We have a standard - ANSI X3.64.

It doesn't address EBCDIC.  If you want to create your own standard that
does, nobody is going to stop you.

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).

Apparently you think you need a language extension for something
you've already implemented.  Odd.

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:

It's from https://github.com/jrnutt/msged .

[...]

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.

The (ancient and obsolete) 1990 ISO C standard does not support your
expectation.

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.

OK, you have your opinion about where it "belongs".  I won't continue
arguing about it.

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.

Or for any other character set that satisifies a few requirements, and
which may or may not have a character called "escape".

Apparently by "C90-compliant" you mean "100% portable", which is
certainly not what I mean by it.  The source code for microemacs and
msged is not 100% portable.  If you want to work on making it so, knock
yourself out.

(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?

Use any editor you like.  You've now said you already have a working
microemacs for mainframe operating systems.

[...]

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.

What do you mean by "every compiler"?  I thought all you cared
about was a (currently nonexistent) public domain C90 compiler.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */