Dependable C

Posted by RossBencina 2 hours ago

Comments

Comment by chubot 17 minutes ago

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

Comment by torstenvl 1 hour ago

> 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.

Comment by agumonkey 57 minutes ago

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)

Comment by AlotOfReading 44 minutes ago

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).

Comment by torstenvl 18 minutes ago

I don't think clang is being "aggressive" on ARM, it's just that all aarch64 targets support fma. You'll get similar results with vfmadd213ss on x86-64 with -march=haswell (13 years old at this point, probably a safe bet).

    float fma(float x) {
        return 3.0f * x + 1.0f;
    }

Clang armv8 21.1.0:

    fma(float):
        sub     sp, sp, #16
        str     s0, [sp, #12]
        ldr     s1, [sp, #12]
        fmov    s2, #1.00000000
        fmov    s0, #3.00000000
        fmadd   s0, s0, s1, s2
        add     sp, sp, #16
        ret

Clang x86-64 21.1.0:

    .LCPI0_0:
        .long   0x3f800000
    .LCPI0_1:
        .long   0x40400000
    fma(float):
        push    rbp
        mov     rbp, rsp
        vmovss  dword ptr [rbp - 4], xmm0
        vmovss  xmm1, dword ptr [rbp - 4]
        vmovss  xmm2, dword ptr [rip + .LCPI0_0]
        vmovss  xmm0, dword ptr [rip + .LCPI0_1]
        vfmadd213ss     xmm0, xmm1, xmm2
        pop     rbp
        ret

Comment by _kst_ 47 minutes ago

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.

Comment by vnorilo 39 minutes ago

And yet modern assembly does not correspond 1:1 to the micro-ops the CPU runs or even necessarily the order in which they run.

Both ISA-level assembly and C are targeting an abstract machine model, even if the former is somewhat further removed from hardware reality.

Comment by keyle 1 hour ago

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.

Comment by Joel_Mckay 1 hour ago

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...

Comment by keyle 29 minutes ago

What are you actually answering to?

Comment by Joel_Mckay 2 minutes ago

Reply to bypass a nonsense slop-article that doesn't actually offer any legitimate insights into workmanship standards.

Follow the 10 rules on the single wiki page, and C becomes a lot less challenging to stabilize. Could also look at why C and Assembly is still used where metastability considerations matter. If you spend your days in user-space Applications, than don't worry about it... =3

Comment by vlovich123 1 hour ago

C is simply unforgiving, amateur or not.

Comment by uecker 13 minutes ago

Programming is unforgiving.

Comment by aw1621107 58 minutes ago

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++/

Comment by fsckboy 55 minutes ago

what's the difference between goal and intent?

Comment by aw1621107 39 minutes ago

What I was thinking was something like the difference between "what" and "why". I probably could have worded that better...