As a boring platform for the portable parts of boring crypto software, I'd like to see a free C compiler that clearly defines, and permanently commits to, carefully designed semantics for everything that's labeled "undefined" or "unspecified" or implementation-defined" in the C "standard" (DJ Bernstein)
And yeah I feel this:
The only thing stopping gcc from becoming the desired boringcc is to find the people willing to do the work.
The text following this heading seems to take the opposite view. I suspect this is a typo.
However, I think the heading is accurate as written. The "C is not a high level assembler" crowd, in my view, is making a category error, conflating C itself with an ISO standard and abstract machine concept coming decades later.
By the same token, "C is a high level assembler" is a gross oversimplification.
I see a huge semantic gap between assembly language and C.
An assembly language program specifies a sequence of CPU instructions. The mapping between lines of code and generated instructions is one-to-one, or nearly so.
A C program specifies run-time behavior, without regard to what CPU instructions might be used to achieve that.
C is at a lower level than a lot of other languages, but it's not an assembly language.
C is a programming language. It makes for a very shitty high level assembler.
Here's a trivial example clang will often implement differently on different systems, producing two different results. Clang x64 will generally mul+add, while clang arm64 is aggressive about fma.
x = 3.0f*x+1.0f;
But that's just the broad strategy. Depending on the actual compiler flags, the assembly generated might include anything up to multiple function calls under the hood (sanitizers, soft floats, function profiling, etc).
Languages like C are simply very unforgiving to amateurs, and naive arbitrary code generators. Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
Honestly as a hobbyist programmer I'm more interested in knowing which exact platforms/compilers that don't support these patterns and why should I care about them. Even better if the author can host a list of "supported platforms" that's guaranteed to work if people's projects invest in the style.
On an iPad I can't read the web page at all. The insert at the upper right overlies and obscures the main body of text.
It'd also be a good starting point to be more concrete in your ambitions. What version of C is your preferred starting point, the basis for your "Better C"?
I'd also suggest the name "Dependable C" confuses readers about your objective. You don't seek reliability but a return to C's simpler roots. All the more reason to choose a recognized historical version of C as your baseline and call it something like "Essential C".
There was also "boringcc"
https://gcc.gnu.org/wiki/boringcc
As a boring platform for the portable parts of boring crypto software, I'd like to see a free C compiler that clearly defines, and permanently commits to, carefully designed semantics for everything that's labeled "undefined" or "unspecified" or implementation-defined" in the C "standard" (DJ Bernstein)
And yeah I feel this:
The only thing stopping gcc from becoming the desired boringcc is to find the people willing to do the work.
---
And Proposal for a Friendly Dialect of C (2014)
https://blog.regehr.org/archives/1180
The idea is interesting but unfortunately the actual articles are riddled with spelling errors, typos, missing words, sentences that cut off before
And so on. Is this a work-in-progress thing not meant for public consumption yet?
> C isn't not a high level assembler
Hmm.
The text following this heading seems to take the opposite view. I suspect this is a typo.
However, I think the heading is accurate as written. The "C is not a high level assembler" crowd, in my view, is making a category error, conflating C itself with an ISO standard and abstract machine concept coming decades later.
By the same token, "C is a high level assembler" is a gross oversimplification.
"C isn't not a high level assembler" indeed.
What would you say C is beyond the high-level assembler ? genuinely curious (i kinda hold that belief personally but i'm not a c programmer by trade)
I see a huge semantic gap between assembly language and C.
An assembly language program specifies a sequence of CPU instructions. The mapping between lines of code and generated instructions is one-to-one, or nearly so.
A C program specifies run-time behavior, without regard to what CPU instructions might be used to achieve that.
C is at a lower level than a lot of other languages, but it's not an assembly language.
1 reply →
C is a programming language. It makes for a very shitty high level assembler.
Here's a trivial example clang will often implement differently on different systems, producing two different results. Clang x64 will generally mul+add, while clang arm64 is aggressive about fma.
But that's just the broad strategy. Depending on the actual compiler flags, the assembly generated might include anything up to multiple function calls under the hood (sanitizers, soft floats, function profiling, etc).
2 replies →
There are many problems with this website. I couldn't actually find the meat of it, where the intro page talked about what it could do for us.
Inconsistent titles, stuff labelled [TOC].
It might be a work in progress and not really ready to be shared widely.
Languages like C are simply very unforgiving to amateurs, and naive arbitrary code generators. Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
Vibe coders usually offer zero workmanship (especially with the web), and are enamored with statistically salient generated arbitrary content. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
What are you actually answering to?
2 replies →
C is simply unforgiving, amateur or not.
1 reply →
Wow, lots of C related posts in the last few days. Is that because of vibecoders rediscovering it?
Trolling for rage drives engagement. =3
Honestly as a hobbyist programmer I'm more interested in knowing which exact platforms/compilers that don't support these patterns and why should I care about them. Even better if the author can host a list of "supported platforms" that's guaranteed to work if people's projects invest in the style.
This list of rules applies to most languages:
https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
A bit of history where these rules came from, and why they matter. =3
"Why Fighter Jets Ban 90% of C++ Features"
https://www.youtube.com/watch?v=Gv4sDL9Ljww
Is there a way to force reader mode or force text not to be justified like that? I'm having a difficult time reading the content (on mobile at least).
On an iPad I can't read the web page at all. The insert at the upper right overlies and obscures the main body of text.
It'd also be a good starting point to be more concrete in your ambitions. What version of C is your preferred starting point, the basis for your "Better C"?
I'd also suggest the name "Dependable C" confuses readers about your objective. You don't seek reliability but a return to C's simpler roots. All the more reason to choose a recognized historical version of C as your baseline and call it something like "Essential C".
This is reminiscent of Orthodox C++ [0], though I think it's perhaps more similar in goal than intent.
[0]: https://bkaradzic.github.io/posts/orthodoxc++/
what's the difference between goal and intent?
A goal is what, intent is why. And a same goal could be motivated by different intents.
What I was thinking was something like the difference between "what" and "why". I probably could have worded that better...