Sujet : Re: 80386 C compiler
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 25. Nov 2024, 19:23:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241125101701.894@kylheku.com>
References : 1 2 3
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2024-11-24, Paul Edwards <
mutazilah@gmail.com> wrote:
"Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message
news:vhvsm9$2bmq9$1@dont-email.me...
On 24.11.2024 15:00, Paul Edwards wrote:
>
I have been after a public domain C compiler for decades.
[...] I'm after C90 written in C90.
>
Why formulate the latter condition if you can bootstrap?
(Did you mean; written in a "C" not more recent than C90?)
>
Yes - written in C90 so that it can be maintained with
just knowledge of C90.
>
And also written in C90 so that it is written naturally
for a C90 programmer, not using a subset of C90
But, do yourself a favor and, have it as an extension to allow
non-constant expressions to allow block scoped aggregates:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
(You don't have to use it in the source code of the thing,
so it can be boostrapped by other C90 compilers without
the extension.)
Also, pin down the truncation behavior of / and % to match C99.
(Though, again, without relying on that in the C90 source
of the compiler.)
Define the behavior of a [0] array at the end of a struct,
so that the C90 struct hack is "blessed" in your implementation.
The C99 flexible array member cannot be used, after all.
You can have it so that [0] has the same semantics as C99 []
in that role.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca