Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Tue, 26 Nov 2024 21:59:06 -0800
Organization: None to speak of
Lines: 136
Message-ID: <87ttbtjjyt.fsf@nosuchdomain.example.com>
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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 27 Nov 2024 06:59:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="94b120d49bf499dd826bd7ffb8691177";
	logging-data="4085883"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+qn6MwXqsbAKHQdGugEEjM"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:jPpwjMUKiBX45zLnFZc3TxFKbds=
	sha1:1KV3TXj7Z2EDq+dzcC0YhsXmsDA=
Bytes: 6098

"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 */