Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang vs. Clang

blog.cr.yp.to

Post reply on HN
Print view View original

361–370 of 405 posts

Re: Clang vs. Clang

#361

Post by account42 »

Surprised to see such an incoherent and trite rant from djb.

Compilers are not your enemy. Optimizing compilers do the things they do because that's what the majority of people using them want.

It also mixes in things that have nothing to do with optimizing compilers at all like expecting emulation of 64-bit integers on 32-bit platforms to be constant time when neither the language nor the library in question have ever promised such guarantees. Similar with the constant references to bool as if that's some kind of magical data type where avoiding it gives you whatever guarantees you wish. Sounds more like magical thinking than programming.

I'd file this under "why can't the compiler read my mind and do what I want instead of just what I asked it to".

Re: Clang vs. Clang

#362

Post by tsimionescu »

saagarjha wrote: post #360
tsimionescu wrote: post #352

Earlier quoted context omitted.

A state in which memory is not expected to be based on the theoretical semantics of the program. For example, if you do an out of bounds write in C, you can set some part of an object to a value it never should have according to the text of the program, simply because that object happened to be placed in memory next to the array that you wrote past the end of. According to the semantics of the C abstract machine, the…

This is just UB.

Yes, this is an example of UB leaving memory in a bad state.

If you want an example of something that is not UB leaving memory in a bad state, here is some Go code:

  global := 7;
  func main () {
    go func() {
      global = 1000000;
    }()
    go func() {
      global = 10
    }()
    fmt.Printf("gloabl is now %d")
  }
The two concurrent writes may partially overlap, and global may have a value that is neither 7 nor 10 nor 1000000. The program's memory is in a bad state, but none of this is UB in the C or C++ sense. In particular, the Go compiler is not free to compile this program into something entirely different.

Edit: I should also note that a similar C program using pthreads or win32 threading for concurrent access is also an example of a program which will go into a bad state, but that is not UB per the C standard (since the C standard has no notion of multithreading).

Re: Clang vs. Clang

#364

Post by account42 »

tsimionescu wrote: post #210
opnitro wrote: post #183

Earlier quoted context omitted.

I think the "do the normal" thing is very easy to say and very hard to do in general. Should every case of `a / b` inject a `(b != 0) && ((a != INT_MAX && b != -1))`? If that evaluates to `true` then what should the program do? Or: should the compiler assume this can't happen. Languages with rich runtimes get around this by having an agreed upon way to signal errors, at the expense of runtime checking. An example dir…

The compiler should emit the code to add one to a, and then code to check if the result is greater than a. This is completely evident, and is what all C and C++ compilers did for the first few decades of their existence. Maybe a particularly smart compiler could issue a `jo` instead of a `cmp ax, bx; jz `. The for loop example is silly. There is no reason whatsoever to add an overflow check in a for loop. The code of…

If you want the compiler to output exactly the code as written (or as close as possible to it for the target architecture), then most compilers support that. It's called turning off optimizations. You can do that if that's what you want.

Optimizing compilers on the other hand are all about outputting something that is equivalent to your code UNDER THE RULES OF THE LANGUAGE while hopefully being faster. This condition isn't there to fuck you over its there because it is required for the compiler to do more than very very basic optimizations.

Re: Clang vs. Clang

#365

Post by account42 »

SleepyMyroslav wrote: post #231
pertymcpert wrote: post #192

Earlier quoted context omitted.

You would be very wrong on that last point.

Fun fact you and GP both right. Goals of 'local' build a programmer does to check what he wrote are at odds with goals of 'build farm' build meant for end user. Former should be optimized to reduce build time and latter optimized to reduce run-time. In gamedev we separate them as different build configurations.

Right and if anything, compilers are conservative when it comes the optimizations parameters they enable for release builds (i.e. with -O2/-O3). For most kinds of software even a 10x further increase in compile times could make sense if it meant a couple of percent faster software.

Re: Clang vs. Clang

#366

Post by account42 »

userbinator wrote: post #240
uecker wrote: post #228

Earlier quoted context omitted.

I do not think there is a reason to fork. Just contribute. I found GCC community very welcoming. But maybe not come in with an "I need to take back the compiler from evil compiler writers" attitude.

From personal experience, they couldn't care less if they can argue it's "undefined". All they do is worship The Holy Standard. They follow the rules blindly without ever thinking whether it makes sense. But maybe not come in with an "I need to take back the compiler from evil compiler writers" attitude. They're the ones who started this hostility in the first place. If even someone like Linus Torvalds can't get them…

> They're the ones who started this hostility in the first place.

"How dare these free software developers not do exactly what I want."

Talk about being entitled. If you can't manage to communicate you ideas in a way that will convince others to do the work you want to see done then you need to either pay (and find someone willing to do the work for payment) or do the work yourself.

Re: Clang vs. Clang

#367

Post by eschneider »

rbanffy wrote: post #356
eschneider wrote: post #328

Earlier quoted context omitted.

There's nothing terribly difficult to writing specific routines in asm. It's kinda fun, actually. Assembly _in the large_ is hard, just because you need to be next-level organized to keep things from being a mess.

I find it rather easy as long as you don’t have to interact with the OS. That’s where it becomes messy, with inflexible data structures and convoluted arguments in ABIs designed to be used from higher level languages. If you are doing really low level stuff, sometimes it’s worth rolling out your own little RTOS with just the bits and pieces you need. Not that long ago, I realised most 8-bit (and MS-DOS) computer game…

Yeah...Old 8-bit computers didn't exactly have any OS services. :)

Re: Clang vs. Clang

#368

Post by account42 »

hedgehog wrote: post #41
cmeacham98 wrote: post #14

Earlier quoted context omitted.

If your "secure" code is not secure because of a compiler optimization it is fundamentally incorrect and broken.

There is a fundamental difference of priorities between the two worlds. For most general application code any optimization is fine as long as the output is correct. In security critical code information leakage from execution time and resource usage on the chip matters but that essentially means you need to get away from data-dependent memory access patterns and flow control.

Then such code needs to be written in a language that actually makes the relevant timing guarantees. That language may be C with appropriate extensions but it certainly is not C with whining that compilers don't apply my special requirements to all code.

Re: Clang vs. Clang

#369

Post by account42 »

kevingadd wrote: post #102
tbrownaw wrote: post #87

Earlier quoted context omitted.

Staying under the speed limit is, in fact, pretty hard as evidenced by how often drivers fail at it.

It's more complex than that for the example of car speed limits. Depending on where you live, the law also says that driving too slow is illegal because it creates an unsafe environment by forcing other drivers on i.e. the freeway to pass you. But yeah, seeing how virtually everyone on every road is constantly speeding, that doesn't give me a lot of faith in my fellow programmers' ability to avoid UB...

And to be specific, some kinds of UB are painfully easy to avoid. A good example of that is strict aliasing. Simply don't do any type punning. Yet people still complain about it being the compiler's fault when their wanton casting leads to problems.

Re: Clang vs. Clang

#370

Post by rbanffy »

eschneider wrote: post #367
rbanffy wrote: post #356

Earlier quoted context omitted.

I find it rather easy as long as you don’t have to interact with the OS. That’s where it becomes messy, with inflexible data structures and convoluted arguments in ABIs designed to be used from higher level languages. If you are doing really low level stuff, sometimes it’s worth rolling out your own little RTOS with just the bits and pieces you need. Not that long ago, I realised most 8-bit (and MS-DOS) computer game…

Yeah...Old 8-bit computers didn't exactly have any OS services. :)

Some very minimal things such as reading or writing to disk or files, reading the keyboard, or other very simple activities
Post reply on HN