> If the sample code makes use of single language extension not part of ISO C

What are you even arguing right now? (Btw -ansi compiler flag)

> Smart-arse is comparing C versus JavaScript

I chose JavaScript to make the idea of a spectrum clearer using extremes. I can do C++ if you like. The machine doesn’t care about destructors, move, concepts, initializer lists, virtual methods, launder, or inheritance. You are programming against an abstract model further divorced from how x86 CPUs work.

That many features are not ISO, and any language can have extensions just like C, nothing special there.

To me choosing JavaScript as example against C, feels like the Tiger Beetle guy that initially chose JavaScript and then went to Zig because JavaScript did not deliver, go figure.

So many systems languages to chose from since 1958.

This responds to nothing in my comment.

So do you want to "rewrite" some C code in C++ to think you made a point? I think you should do C# or Java.

What about you do xxHash? Should be quite basic, not a lot of complicated structures. https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h

Or what about you do an audio or video codec? Or an operating system?

Not going to paste any of my own code, because any non-trivial stuff is hundreds to thousands of lines. But one more example (that I recently did myself): Create a block allocator (power of two blocks) with bookkeeping in shadow memory (administered in individually committed zones representing virtual memory regions of 64 MB (2^26)). Any used memory has bookkeeping support for being sub-allocated at any and all levels up from 64 KB (2^16) to 64 MB (2^26), and even higher (by joining committed regions). Individual blocks are collected (using intrinsic linking, because no memory allocation) in a hierarchy of pools of same-sized chunks that have the same parent, and can be recursively sub-allocated on any smaller chosen power-of-2 level, and finally be consumed in linear fashion (arenas). Blocks are pooled with a moderate retain policy (watermark system) to allow subsystems to almost completely avoid any system calls and avoid inter-thread synchronisation. The memory overhead must be below 1% even though it's totally flexible (as said has metadata for all levels from 64 KB up).

The bookkeeping should function on 32-bit systems (small virtual space, occupancy range from megabytes to 3 GB) as well 64-bit systems (2^48-2^57 bytes of virtual address space, occupancy range from megabytes to hundreds of gigabytes) with reasonable overhead compared to actual usage.

This requires intrusively linked lists, occupancy bitmasks, bit-counting and bit-prefix counting, OS syscall access (virtual memory), pointer arithmetic (alignment needed to address shadow bookkeeping memory) and thread synchronisation. The reference code is >> 95% pure ISO C++11 (could be C99 with few changes), with a little platform code glued in. It works on Windows but it could be ported to Linux in a few hours. It supports a mostly-immediate-mode GUI with hundreds of thousands (maybe millions?) of small variable-sized allocations per second. Allocation has almost completely disappeared from the CPU profile, well below 1% of CPU usage.

I said any systems programming language, and stated the rules, so I gather you don't want to play this game after all.

> Or what about you do an audio or video codec? Or an operating system?

There are already plenty of examples out there, Claude can probably help you there regarding history of such products not written in C, or where C required help from Assembly code.

You can start by researching IBM i, z/OS, OS 2200, Xerox Alto, DirectX and Metal (C++ for the most part, and Objective-C++ on the 2nd)

> This requires intrusively linked lists,....

And the C99 version is impossible to be written in Ada95 because?

Who uses Ada95 or whatever? You are fighting strawmans, nobody has made the claims you imply. My personal opinion is just that low-level access is essential to make interesting and performant programs. Object-type fluff doesn't help with that, it's getting in the way.

> Smart-arse is comparing C versus JavaScript, instead of C vs C++, for example.

Using C++ as your other comparison point when arguing that C isn't low level is by far the most smartass idea in this thread.

Not at all, because for C heads, C++ can't do what C does, for whatever imaginary reasons.

I challenge you to find one random person making that claim and to present it with a straight face. What kind of ghosts are you fighting?

Yeah, I see plenty of people complain that C++ can't be simple because devs will keep reaching into the cookie jar, but that's not the language being unable to do something C can.

The only complaint I see about C++ not being capable is the correct observation that more platforms have C compilers than C++.

Either way, C++ spans a big range that goes just as low level as C. Even if these complaints are real they don't make it a reasonable comparison point for the "C is actually high level" argument.

Requesting a block of system memory, by address, and writing to it.

This is common with C, when interfacing with hardware.

Define how you want to write to that system memory without OS syscall.

What exact C code did you had in mind?

So that the counter example is close enough to it in exposing the same semantics.