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

>>40
it doesn't sound stupid to me. Any reason why you say that?

I think the biggest force in effect here is that lesser programmers are having their ego threatened.

I'm talking about the kind of guys who are proud of themselves for memorizing the various C standards, knowing all the exact UB talking points you can pull out to force someone to admit you know C better than them.

They're scared and biting back because they know their 'talent' is being nullified.

>>42
I see a different thing: destroying the portability of C because they don't want to write x86 assembly.

>>43
Nobody but cudder should be forced to write x86 assembly in 2015.

>>36
You don't even understand the fucking conversation.

If you standardized what your compiler/environment does with UB, you have fixed it. If you move to a language that isn't as godawful and godforsaken as C, you have fixed it.

Trying to trap & report UB is fucking stupid, and the halting problem is part of and/or proof of that idiotic response to this thread.

Simply read UB as ``Not allowed''

Hey Doc, it hurts when I slam my head into the wall.

>>43
That's perfectly reasonable. Only an autistic turbonerd like Cudder would want to memorize and mentally manage the 500 stage pipeline on x86. Close off the difficult areas and let the optimizer go to work on it.

>>12
I'm a CEO of four large companies, and a professor at Harvard and a spaceman. I just got back from my last mission to space, and am also a racecar driver so I will have to go racing soon, but maybe I'll have some time before then. If some females don't call me up to do sex with them, because I'm also a big sex-haver and do it like many times a day. I graduated excelsior cum laude from Space University 25 years ago, and apparently they didn't teach me to read directions at Space University because I did not notice that the OP wants me to reply to the maillist and not post in this thread. So that's why I'm sharing all of this with you guys. I've developed software for the first computer ever, worked at IBM as a bad ass computer inventor, designed the x86 processor, and also developed software for spaceships, and also have lots of sex with females, and hopefully you will see me as qualified to do some serious PHP development here (C is obsolete and only sex non-havers use it).

>>45

If you standardized what your compiler/environment does with UB, you have fixed it.

Trying to trap & report UB is fucking stupid, and the halting problem is part of and/or proof of that idiotic response to this thread.

Let me see if I understand. So when your compiler tells you that you're using a not definitely initialized variable, you have fixed the UB problem. But when your code analyzer tells you that you're using a not definitely initialized variable, you are being fucking stupid and halting problem proves you wrong?

I'm beginning to suspect that you fuckers have no clue what UB actually is, I mean, which cases are marked as UB in C, so you're talking out of your asses about solutions to some entirely imaginary problematic cases.

How applicable is the Halting problem on non-Turing machines anyway? Oh, you thought your shitputer was Turing complete? Well what would happen if it runs out of memory? Nah, it's just a finite state machine with lots of states. A static analyzer doesn't have to check an infinite problem space like the Halting problem falls victim to.

>>51

Oh, you thought your shitputer was Turing complete?

Obviously as soon as you add the ability to interface with unlimited external storage (via internet for example) all you need is enough states to implement an UTM.

>>52
Thw tape is infinite, so the states in a TM is irrelevant. But expand your memory to the entire universe and it's still finite. The DFSM state count will grow with O(2²ⁿ) where n is the tape size of the shitputer, but it is still finite.

>>52

unlimited external storage

tell me where I can find this "unlimited external storage" device

SHITBABBY RETARDS TALKING ABOUT TURING MACHINES

HOLY SHIt

THIS ISN"t INTRODUCTION TO UNDERGRAD COMPUTER SCIENCE

FUCK ALL THE WAY OFF.

WHAT ARE YOUD OING HERE.

>>54
Have you tried /dev/null?

>>1-55
People who want to throw out everything written in C and rewrite it in Rust are as bad as people who want to use JavaScript for everything. And I like JavaScript.

>>53,54

You mongos don't know the difference between "unlimited" and "infinite"? Are you in the middle school or something?

>>57
Doesn't matter. So long as the memory required is finite, a FSM can parse the language. L={aⁿbⁿ|n is unbounded} ∉ RL. L={aⁿbⁿ|n<10}, for example, is a regular language. The distinction between unlimited, arbitrary, unbounded, and infinite are irrelevant.

STOP TALKING

EVERYONE FUCK OFF

>>56
/dev/null is readonly

>>55
Whom are you quoting?

>>50
Fixing UB in C is an oxymoron. Any arguments anybody has on how it would possibly manifest helps to prove how fucking broken it all is.

>>51
The halting problem has nothing to do with the memory footprint, you ass tard.

>>63
Perhaps the fact that it's formulated only for a machine with infinite memory?

>>63
>>64
GET THE FUCK OUT THIS ISN'T UNDERGRADUATE CS LAB
YOU ROTARDS

>>65
OPTIMISE YOU ARE FUCKING QUOTES

>>56
C will never be secure. They will continue finding buffer overflows, even in libc itself, for all eternity. If you want the `internet of things` to be anything else than the internet of ubiquitous botnets, you will have to accept some temporary setbacks in functionality. Security can not be added as an afterthought.

>>64
Why don't you just shut your /dev/random-connected face hole and kill yourself, you ignorant fuck?

The halting problem has nothing to do with Turing machines or finite/infinite or bounded/unbounded memory. You're just spewing terms that you've heard from the lowest level CS morons who barely understood what they meant.

I mean this sincerely. Put a bullet through your head, take a dive under a train, jump off a bridge, anything to rid the world of yourself.

>>68
Explain then how a finite system can possibly not be checked for halts?

I think that it is you who is a retard. Are you one of the retards who insist that hello-world can never be shown to halt? I think you may be!

Please read: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf or one of the many other papers on this.
On the Halting Problem of Finite-State Programs

Abstract. The undecidability of the halting problem is a well-known research result of theoretical computer science, dating back to Turing’s work in 1936. Nevertheless, it is commonly known that the halting problem on finite-state computer systems is decidable. Thus, any undecidability proof given for the halting problem must imply that it does not apply to finite-state computer systems.
The aim of this paper is to deepen the understanding of why the undecidability proofs of the halting problem cannot be instantiated as finite-state programs. To bridge the gap between theory and practice, the arguments are based on simple mathematics rather than an extensive use of abstract formalisms.

See, should be simple enough for even a simpleton like you!

>>69
Are you the "jews invented infinity" retard or did you catch it from him?

>>68
Fuck off, idiot.

>>70
Are you the "I've got nothing to say on the topic so I'm picking on the other person with random irrelevant bullshit pretenses" retard or did you catch it from him?

>>70
Do you have anything further to say about the halting problems applicability to finite systems? Several of us are waiting on your apology.

>>69
God fucking damnit, you're such a stupid nigger cunt. This is like CS 101 shit.

Pick some mathematical property of integers, where it is unknown if there are more any integers which meet that property that is greater than the existing largest one found.

Test each integer for that property, ++i.

Will it ever halt?

Now, eat a bullet.

can everyone just stop asking about the halting problem

this is literally reddit-tier

this is shit you should be asking on r/askscience or r/eli5

not here. /prog/ was always full of people who have long undertsand BASIC FACTS about programming

If this compiler doesn't drill holes through rock, I'm not interested.

>>74
If i is bounded, if it does not enumerate over all of N, if there are only a finite values to check, then that property can be exhaustively checked in finite time, and the sytem must halt in finite time.

Simply put: THE HALTING PROBLEM DOES NOT APPLY HERE. What do you not fucking understand? The halting problem is only concerned with infinite machines. Are you going to fight this fucking hard when I tell you that regexp can parse HTML if I guarantee that the recursion depth will never exceed the pumping number of the regexp?

>>75
No, we will never stop discussing it, and we will follow you into other threads until you stop either being a retarded fucking cunt who refuses to listen, you learn how to not be so god damn obvious in your posts that you stick out from everyone else and can be instantly identified, or you go the fuck back to /g/.

>>77
the fuck you talking about retard newfag?

>>77
do you really think you're intelligent for explaining basic facts about computing to a retard?

if that's what makes you feel good go hang around on IRC or something, your postst are not wanted here.

>>74,75,78,79-idiot
You are unbearable and insufferable and you are embarrassing yourself. Please, seriously, just fuck off. This is not fucking 4chan.