Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul Edwards" <mutazilah@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Wed, 27 Nov 2024 21:50:35 +0800
Organization: A noiseless patient Spider
Lines: 213
Message-ID: <vi783h$1c3i$1@dont-email.me>
References: <vhvbhf$28opb$1@dont-email.me> <vhvsm9$2bmq9$1@dont-email.me><vi0dt1$2el7m$1@dont-email.me> <20241125101701.894@kylheku.com><qrp9kjd09n2v3srmabqccmnsbr1r6nkm2m@4ax.com><20241125132021.212@kylheku.com><875xo9ln93.fsf@nosuchdomain.example.com><vi5elj$3kdmr$1@dont-email.me><871pyxljfc.fsf@nosuchdomain.example.com><vi6adc$3shu6$1@dont-email.me> <87ttbtjjyt.fsf@nosuchdomain.example.com>
Injection-Date: Wed, 27 Nov 2024 14:50:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ff511d84c8d989f9586aca77125b5af3";
	logging-data="45170"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+vwibFadJX0AIsmAXUq0+Vx+sQ44RB5Mc="
Cancel-Lock: sha1:GjbCSD2LQ1sM2xhEfL+baoPcCYQ=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Priority: 3
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MSMail-Priority: Normal
Bytes: 9586

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ttbtjjyt.fsf@nosuchdomain.example.com...

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

EBCDIC ANSI is (or can be) identical to ASCII ANSI.
The same text is used to drive the screen. All the characters
have EBCDIC equivalents. They're all displayable ASCII
except for when the escape character is used - and that's
why I proposed adding a formal define for it - so that you
can drive a terminal in a portable manner.

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

Depends on the definition of "need".

Yes I have it working. But it required conditional compilation
for the hex code of the ESC character. That's what I find odd.
That I can write an entire toolchain, including OS, portably
in C90, except for a smalll portion of the editor.

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

Thanks. That is msged 2.x. I am using msged 3.x. Which may
have been created after the original author disappeared,
presumably died.

> > 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 comes very very close. I'm just trying to eliminate that gap
with a reasonable extension.

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

Correct - so I would be introducing something stricter than
C90 - a requirement for the character set to include an ESC,
so that an ANSI terminal can be driven.

And I think there is no avoiding a set of control keys so that
the microemacs keystrokes can be supported.

So yeah - ASCII and EBCDIC would both qualify. Other
theoretical character sets would be supported too. But yes,
some other real or theoretical character sets would not be
supported, so you can't use "the" portable version of
microemacs to drive an attached ANSI terminal.

> Apparently by "C90-compliant" you mean "100% portable", which is
> certainly not what I mean by it.

Well - "strictly conforming" is the proper term I believe.

I want to be strictly conforming to something close to C90
that takes into consideration the need for fullscreen apps
on another ANSI standard (X3.64).

> The source code for microemacs and
> msged is not 100% portable.  If you want to work on making it so, knock
> yourself out.

Right - that's exactly what I'm doing. But I cannot do so if I
need to hardcode the code point of the ESC character.

Something has to give.

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

For 2 somewhat independent (rewrites) mainframe operating systems, yes.

It should be possible to get them to work under other mainframe
operating systems (ie MVS TSO) too, with an appropriate
attached terminal (likely emulated by a PC as is almost
universally done now). Would likely work on z/OS USS or
whatever it is called too, but I've never investigated that.

> >> 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
========== REMAINDER OF ARTICLE TRUNCATED ==========