High C Compiler – A C language extension ahead of its time

E.g. for a function:

    void my_func(const bla_t* bla);
   

    my_func(&(bla_t){ .x = 123, .y = 542 });

C++20 has a much more restricted designated init feature (basically useless for complex structs), but one nice thing in C++ is that default values can be declared right in the struct declaration.

Objects are good enough and it would add complexity for minimal reward.

As to your question, I share this feeling. Naming parameters must be standard feature in every language. Absolute majority of functions would benefit from verbose calling syntax.

Get used to writing your functions using objects for the arguments:

  function myFunc({ foo, bar }) {}

  function myFunc({ foo: 1, bar: "x" })

    struct MyFuncArgs { int foo; char bar; };
    void myFunc(MyFuncArgs args) {}
    myFunc({ .foo = 1, .bar = 'x' });

No, not really. You just have to be aware of them, decide that you want to implement them, then sit down and implement them.

For numeric literals with underscores the implementation is rather trivial, you fiddle a bit with the lexer to make it skip the underscores during the text consumption and value conversion.

For named arguments the main problem is not in the implementation itself, it's deciding on what semantics you want when you mix named and positional parameters: e.g. if you have f(a,b,c) then what does f(1, 2, a=3) or f(c=1, 2, 3) or f(b=2, 3, a=1) mean?

TypeScript's pretty insistent on not adding features to the language that can't be "compiled" just by stripping types away. There was a little bit of slack around this early on (enums, most notably) but these days something like named parameters would probably be a non-starter until/unless JS implemented them first.

https://dl.acm.org/doi/pdf/10.1145/69622.357187

Wild!

Makes one wonder how something could have evolved if it took C and made it more “functional” and/or smalltalk-ish, without going the dynamic way of ObjectiveC.

I don’t exactly love C++ but I find it very useful. Maybe I could have loved that other never conceived C offspring.

The POSIX standard isn't the C standard though (for better or worse).

Especially on Windows with MSVC "obvious" things like this are traditionally a royal PITA (which also means that a lot of C code coming from the UNIX world simply doesn't build on MSVC even though MSVC is now a decent standard-C compiler again).

But yeah, the C standard is just the minimal common subset of what C compilers offer. The good stuff is all in Clang and GCC extensions.

<pthreads.h> is POSIX, it has never been - and still don't is! - part of the C standard. In particular, MSVC only supports it through third party libraries.

However, C11 added cross-platform thread support with <threads.h>: https://en.cppreference.com/w/c/thread. I wouldn't call that "stupid stuff nobody needs".

I actually used that compiler over 25 years ago, it generates Intel OMF files with 8086/80186/80286 - As I recall one can select the target.

So post compiling, one should be able to link the result to target a DOS machine, VM, or even Dosbox.

I'd suggest porting it, but rather simply simulating the FlexOS SVCs, since it doesn't really need any of the RT capabilities, merely the file access, memory allocation / free, and possibly execution (COMMAND SVC).

The package contains two forms of the compiler, a single executable version, and an overlaid version. The non overlaid version would be easiest to get working in such a simulated approach, as one would not have to implement the OVERLAY SVC.

[1]: https://open-std.org/JTC1/SC22/WG14/www/docs/n3194.htm

there are 18 sovereign countries in https://en.wikipedia.org/wiki/List_of_countries_and_dependen... with smaller populations than fujitsu, and 31 with smaller economies than fujitsu https://en.wikipedia.org/wiki/List_of_countries_by_GDP_(nomi...

The post hoc insistance on using it's rebrand helps with the 'othering' of making it sound like a foreign company doing all the dodgy shit.