boring C compiler

https://groups.google.com/forum/m/#!topic/boring-crypto/48qa1kWignU

this site requires javascript to view.. it's a fucking plain text message.. anyway:

14:40 D. J. Bernstein
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". This compiler will provide a comprehensible foundation for
people writing C code, for people auditing C code, and for people
formally verifying C code.

For comparison, gcc and clang both feel entitled to arbitrarily change
the behavior of "undefined" programs. Pretty much every real-world C
program is "undefined" according to the C "standard", and new compiler
"optimizations" often produce new security holes in the resulting object
code, as illustrated by

https://lwn.net/Articles/342330/
https://kb.isc.org/article/AA-01167

and many other examples. Crypto code isn't magically immune to this---
one can easily see how today's crypto code audits will be compromised by
tomorrow's compiler optimizations, even if the code is slightly too
complicated for today's compilers to screw up. A boring C compiler will
eliminate these nasty surprises; it will prioritize predictability.

I should note that this plan, throwing away gcc and clang in favor of a
boring C compiler, isn't the only possible response to these types of
security holes. Here are several other responses that I've seen:

* Attack the messenger. "This code that you've written is undefined,
so you're not allowed to comment on compiler behavior!" The most
recent time I saw this, another language lawyer then jumped in to
argue that the code in question _wasn't_ undefined---as if this
side discussion had any relevance to the real issue.

* Say that the C "standard" allows gcc and clang to do whatever they
want to all of these "undefined" programs. Yes, we know that it's a
stupid "standard"; that isn't the question. What do we do about the
resulting security problems?

* Blame the security holes on the C programmers who wrote "undefined"
programs. This _might_ be reasonable if there were a plausible plan
to reduce the fraction of "undefined" programs from ~100% to ~0%,
but there isn't. Even if there were, how would this massive code
revision be better than keeping the code and switching to a boring
C compiler?

* Claim that earthquakes in the behavior of "undefined" programs will
teach C programmers to stop writing such programs. "That'll show
'em!" But the reality is that this hasn't worked and won't work.

* Claim that all we need is for some particular "undefined"-catching
tool to be widely used. In fact, these tools are full of false
positives and false negatives; at best they catch a few limited
types of "undefined" behavior, not changing the big picture.

* Claim that a boring C compiler can't possibly support the desired
system _performance_. Even if this were true (which I very much
doubt), why would it be more important than system _correctness_?

Overall I think that these people simply don't understand what most C
programmers want. A boring C compiler will very quickly gain users---not
merely for security but also for predictability in general; people will
appreciate, e.g., having variables automatically initialized to 0. Of
course, the compiler has to support the usual C ABI, so that programs
compiled with this compiler can be linked to libraries compiled with
other compilers (including other languages), and vice versa, allowing an
incremental upgrade process.

I'm told that the Plan 9 compiler tries to be somewhat predictable---

http://article.gmane.org/gmane.os.plan9.general/76989

---but it still leaves many things unspecified, and I'm under the
impression that it has its own ABI. There's a "Fail-Safe C" compiler
that sounds like it defines much more, including safe semantics for
buffer overflows---

https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html

---but it's clear that this has its own ABI. There are various projects
such as

http://www.doc.ic.ac.uk/~awl03/projects/miro/

that add more useful semantics to some parts of C _without_ changing the
ABI, but the same compilers will happily screw up other parts of C.
There's a "Friendly C" proposal that targets other parts of C more
relevant to core crypto---

http://blog.regehr.org/archives/1180

---but the big picture is still tons of misguided flexibility for the
compiler writer.

---Dan

Too long but here are some things I noticed:
``"standard"''
``"undefined"''
``"optimizations"'' (LOL he can't even write. It is actually optimisations)

I have a solution, maybe, just maybe follow what the standard says for once and stop behaving like a stupid fuck who its okay because it just work on my machine. Asshat

A actual solution would be to use an implementation that tries to show up the errors as much as possible. And by implementation I do not mean only the compiler but also the standard library and the underlying architecture as well. Instead of covering your diarrhea in the sand, try to find the cause of it.

Bernstein

Shalom!

>>2
back to your marvel superhero comics lexie

lexie is a derogatory slang word implying that someone is dyslexic

C is a shit language because of all the undefined behavior that the compiler has to wrangle with.

>>1 is just polishing a turd.

Throw the fucking thing out, and use literally anything else. There's no magic to C that any other low-level language can't accomplish, or even subsets of higher level languages.

>>2
the nice colorful pictures are easy to read for you lexie

>>4,7 I am still right.

>>6
What can we do to phase out and deprecate C? Most of us still use software that depends on it.

>>6
This is what Rust people say, and before you know it they've got you brainwashed with their SJW ideology, sucking dicks, infected with HIV, and rewriting the Linux kernel in Rust.

>>1
Ah, I see, D. J. Berenstain is an Ideas Man. In fact I think he might have transcended being an Ideas Man and became an Impetus Man, a being of pure wankery.

I mean, an Ideas Man would at least do something like take John Regehr's proposal and outline some Ideas on how to further eliminate undefined behavior (for example, you can range check all pointer arithmetics using fat pointers), of course leaving the boring stuff like ironing out the details (like how do you track pointer-ness through serialization via memcpy for example) and actual implementation to lesser men.

Not mr. Berenstein though, he wouldn't stoop even to that, he merely conveyed his Strong Opinion that the Job must be Done, mentioned the previous attempts at Getting the Job Done, and rode away into the sunset, his mission of improving human condition complete.

>>11
I am smarter than dan berngstaing.
I have over 4 years experience in javascript which runs in the wbrowser. My profilolio includels: )did the CSS).

I have not publish as many academica papers as him but im still smarter because the things i have produced (my personal blog) are a lot of more imporcance than this stupid dude that thinks hes hot shit after writing an email app. I can write email app too using nodejs.

Why does anyone listen to this "djb" idiot. What a lame 90s-hacker pretentious 'handle'. doesn't he know it's 2016 already? He should get on github and use his real name and a nice photo like I do. I get employment through github dude.

Bceause I'm so smart (compared to him) I made a lo of cool things like new apps. What has he made? Some weird thing that mixes binary numbers about and it s named after an italian dancing move? tell me how exactly is that going to help young african girls get involved in computers...?

I'm smarter than dan beinhtstargi because I got $4000 on a kickstarter ato makea game making gamer: a browser bades games maker tool where you can select from 3 games to make by drag an drog. This empowers people. what hdoes his shit do? some math crap.

everyone lets ignore this 'djb' guy and hope he goes away.

The three currently known posters on /prog/: me, The Sussman, and dang bangstain

14 words

>>9
Source-to-source compilation of C into the preferred target language would be great, as well as the ability to link to C binaries. The latter is already necessary because most OSes only expose a C interface.

>>12
You sound really buttdevastated. Sorry for pooperpunishing you to such an anally anguishing extent!

I think it's the first time I've seen someone tried to whiteknight a male CS researcher though, and how! Wow.

I'm smarter than dan beinhtstargi because I got $4000 on a kickstarter ato makea game making gamer: a browser bades games maker tool where you can select from 3 games to make by drag an drog. This empowers people. what hdoes his shit do? some math crap.

Scratch that, you sound drunk as fuck. On an unrelated note, reminds of a story when two male nerds (acquaintances of acquaintances) were drinking with a female nerd, and at some point started hinting about menage a trois, to which she suggested that they might go and fuck each other if they are so horny, which to her great surprise they did.

Alcohol is known to sexually liberate people, bringing to surface deeply suppressed feelings like your homosexual fantasies about DJB. So no, now I'm not surprised at all.

>>16
smh willy tbh lmao

never posting drunk again

>>1

Claim that all we need is for some particular "undefined"-catching tool to be widely used. In fact, these tools are full of false positives and false negatives; at best they catch a few limited types of "undefined" behavior, not changing the big picture.

These tools ought to be a standard component of every C compiler. One of the biggest issues with C is that you can't generally expect the compiler to warn you about very common errors (the more popular compilers certainly try to do this, but they aren't always an option, and even gcc and clang will silently accept really horrible things even with most of the usual warnings turned on).

Of course, you can't provide useful warnings for everything - that's an unavoidable fact of the way the language is designed - but not warning by default when the compiler knows the programmer has surely screwed up and that it is generating total crap is just not acceptable today.

boring

>>18
It's halting-problem-impossible to catch undefined behavior with static analysis. It would need to be very heavy instrumentation for run-time analysis.

>>20
To catch all undefined behavior, yes. However it's quite possible to identify a decent amount of it with little or no runtime overhead.

Why not have ANDRU analysis and attempt formal proof of the program before compiling?

　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つと ﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　と ﾉ
　ｕ-ｕ （l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ'.　`ｕ-u'

Just use Ada already

Ada more like gayda

also even though it's a big improvement it's not a final solution

>>21
What the fuck is the point if you don't catch all UBs?

>>26
Catching some is better than nothing.

browser bades

>>27
but that's not the point of the OP.

>>20

It's halting-problem-impossible to catch undefined behavior with static analysis

No, it isn't.

tl;dr: most compiler writers are idiots who don't even realise one of the suggestions the standard gives about UB is...

NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

...exactly what most programmers actually want when they use C.

>>20
everyone here knows what the halting problem is. you don't need to tell us about this AMAZING cool thing you just learned yesterday in godel escher bach.

yes it's undecidable, that doesn't imply a program can't detect it in a lot of cases. It is also possible to conservatively reject programs that can't be shown to be safe. This results in only accepting a nontrivial subset of safe programs.

>>31

to terminating a translation ... (with the issuance of a diagnostic message).

...exactly what most programmers actually want when they use C.

>>32
Again with the "a lot of cases". Fuck that and fuck you. That doesn't fix the problem of C being shit. Either you eliminate UB or you don't.

If he's saying most C programmers don't really want to be writing C, I'd say he used to be correct.

However, these days there are so many options. Rust will slowly fill in the final missing pieces as the tooling improves

The remaining C programmers don't write C despite its low-levelness and susceptibility to hard-to-find bugs, but because of them.

>>34

Again with the "a lot of cases". Fuck that and fuck you. That doesn't fix the problem of C being shit. Either you eliminate UB or you don't.

Do you people never actually understood halting problem, for all your elitism and counter-elitism? The HP-based counterexample to static analysis problem looks like "try to prove Goldbach's conjecture, if it's true then dereference a NULL pointer, otherwise just return". Well then, if you want provably safe code you go and mark that code as invalid, problem solved.

All that "but muh halting problem" bullshit is a giant ripe red lutefisk that has nothing to do with any of the real problems with constructing a safe subset of C.

What the fuck does the halting problem have to do with most UB in C? 99% of it is trivial shit that no other language standard has trouble with. Fucking INT_MAX + 1 is UB ferfucksake.

Some filthly crossy crossposted our thread.

johnn...@gmail.com
17:57 (1 hour ago)
Other recipients: d...@cr.yp.to
someone reposted it here http://bbs.progrider.org/prog/read/1450729336

Dec 21 20:12:23 <alice> https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ
Dec 21 20:12:26 <alice> This makes me cringe.
Dec 21 20:13:58 <bob> alice: without reading, why?
Dec 21 20:14:05 <urine> alice: TL;DR
Dec 21 20:16:19 <eve> DJB is a serial reinventer...ignore him
Dec 21 20:16:33 <alice> bob: The guy wants a compiler that has predictable "undefined behavior", "implementation-defined behavior" and "unspecified behavior".
Dec 21 20:16:42 <pilne> so
Dec 21 20:16:43 <mallory> yeah DJB is not the brightest as coders go
Dec 21 20:16:50 <bob> alice: lmao. good luck to him I suppose.
Dec 21 20:16:53 <pilne> tl:dr he has no ideas what he wants
Dec 21 20:16:55 <eve> alice: it's not "the guy", it's DJB...the very definition of NIH WHACKJOB!
Dec 21 20:16:57 <mallory> what an idiot
Dec 21 20:17:16 <eve> I'm surprisedd he hasn't implemented one
Dec 21 20:17:27 <alice> How?!
Dec 21 20:17:44 <eve> he's djb. He reimplements *everything*
Dec 21 20:17:46 <steve> why ... don't just pick another language? Or atleast use a stricter standard like POSIX.
Dec 21 20:17:49 <mallory> I'm a lot smarter than djb
Dec 21 20:18:14 <alice> The request for predictable unspecified behavior is legitimate, but implementated-defined is ALREADY defined, it's the whole purpose, so is the purpose of undefined behavior which shouldn't be used in a program and serves for portability purposes only.
Dec 21 20:18:42 <dan> < eve> DJB is a serial reinventer...ignore him <- this is such a transparently wrong argument that i believe a convincing argument exists that it is low-level trolling
Dec 21 20:19:12 <steve> whats wrong with wanting a stricter standard? ISO C is full of undefined this and undefined that.
Dec 21 20:19:20 <urine> +1
Dec 21 20:20:25 <eve> dan: he reinveted sendmail and bind (to name just the two most egregious...); he *tried* to reinvent DNS (and failed because nobody uses dnscurve). He's a talented guy there's no doubt, but he *is* a serial reinventer

I do not want to be lumped with the "don't reinvent the wheel, use robust Java solutions", but isn't consistent implementation-defined behavior a stupid idea?