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

71–80 of 405 posts

Re: Clang vs. Clang

#71

Post by Conscat »

leni536 wrote: post #18
Conscat wrote: post #4

Fwiw clang has a `clang::optnone` attribute to disable all optimizations on a per-function basis, and GCC has the fantastic `gnu::optimize` attribute which allows you to add or remove optimizations by name, or set the optimization level regardless of compiler flags. `gnu::optimize(0)` is similar to that clang flag. Clang also has `clang::no_builtins` to disable specifically the memcpy and memset optimizations.

"The optimize attribute should be used for debugging purposes only. It is not suitable in production code. " https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute...

That's an interesting note. I wonder why they claim this. As far as I know, `[[gnu::optimize("-fno-tree-loop-distribute-patterns")]]` (or the equivalent #pragma) is required for implementing a memcpy function in C unless you do something funky with the build system.

Re: Clang vs. Clang

#72

Post by layer8 »

nabla9 wrote: post #12
exe34 wrote: post #9

Earlier quoted context omitted.

clang::optnone

"Optimizing compilers that don't allow disabling __all__ optimizations"

It’s not well-defined what counts as an optimization. For example, should every single source-level read access of a memory location go through all cache levels down to main memory, instead of, for example, caching values in registers? That would be awfully slow. But that question is one reason for UB.

Re: Clang vs. Clang

#73

Post by o11c »

dchest wrote: post #53
o11c wrote: post #32

Complains about branching, but doesn't even mention `__builtin_expect_with_probability`.

There's no point in mentioning something that doesn't solve the issue.

It's as close an answer as you're going to get while using a language that's unsuitable for the issue.

And in practice it's pretty reliable at generating `cmov`s ...

Re: Clang vs. Clang

#74

Post by RandomThoughts3 »

dataflow wrote: post #70
RandomThoughts3 wrote: post #68

Earlier quoted context omitted.

> if your battery caught fire just because your CRUD app dereferenced NULL, nobody (well, nobody sane) would point the finger at the app author for forgetting to check for NULL. I think pretty much anyone sane would and would be right to do so. Incorrect code is, well, incorrect and safety critical code shouldn’t use UB. Plus, it’s your duty as a software producer to use an appropriate toolchain and validate the appl…

> I think pretty much anyone sane would and would be right to do so. Incorrect code is, well, incorrect and safety critical code shouldn’t use UB You missed the whole point of the example. I gave CRUD app as an example for a reason. We weren't talking safety-critical code like battery firmware here.

Because your exemple isn’t credible. But even then I don’t think I missed the point, no. You are responsible for what your application does (be it a CRUD app or any others). If it causes damage because you fail to test properly, it is your responsibility. The fact that so many programmers fail to grasp this - which is taken as evidence in pretty much any other domain - is why the current quality of the average piece of software is so low.

Anyway, I would like to know by which magic you think a CRUD app could burn a battery? There is a whole stack of systems to prevent that from ever happening.

Re: Clang vs. Clang

#75

Post by saagarjha »

bluGill wrote: post #33
bigstrat2003 wrote: post #20

Earlier quoted context omitted.

It is, in fact, pretty hard as evidenced by how often programmers fail at it. The macho attitude of "it's not hard, just write good code" is divorced from observable reality.

People write buffer overflows because and memory leaks they are not coreful. The rest of ub are things I have never seen despite running sanitizers and a large codebase.

Perhaps you’re not looking all that hard.

Re: Clang vs. Clang

#76

Post by saagarjha »

jonhohle wrote: post #57
josephcsible wrote: post #28

Earlier quoted context omitted.

> (although, to be fair, he’s usually right.) This is worth emphasizing. I actually can't think of any articles of his other than this one that miss the mark.

I’m not sure this one is wrong, especially if you’ve been bitten by underdocumented compiler or framework changes that modify behavior of previously working code. For example, I have a small utility app built against SwiftUI for macOS 13. Compiling on macOS 14 while still linking against frameworks for 13 results in broken UI interaction in a particular critical use case. This was a deliberate change made to migrate…

No, he’s wrong. What you’re talking about is completely different than what you are: your code doesn’t work because Apple changes the behavior of their frameworks, which has nothing to do with what compiler you’re using. There’s a different contract there than what a C compiler gives you.

Re: Clang vs. Clang

#77

Post by 7qW24A »

dathinab wrote: post #22

> [..] whenever possible, compiler writers refuse to take responsibility for the bugs they introduced I have seldomly seen someone discredit their expertise that fast in a blog post. (Especially if you follow the link and realized it's just basic fundamental C stuff of UB not meaning it produces an "arbitrary" value.)

[dead]

Re: Clang vs. Clang

#78

Post by quietbritishjim »

leni536 wrote: post #23

C and C++ are unsuitable for writing algorithms with constant-time guarantees. The standards have little to no notion of real time, and compilers don't offer additional guarantees as extensions. But blaming the compiler devs for this is just misguided.

That was my thought reading this article. If you want to produce machine code that performs operations in constant time regardless of the branch taken, you need to use a language that supports expressing that, which C does not.

Re: Clang vs. Clang

#80

Post by [deleted] »

twoodfin wrote: post #67
HippoBaro wrote: post #48

Earlier quoted context omitted.

I think the author knows very well what UB is and means. But he’s thinking critically about the whole system. UB is meant to add value. It’s possible to write a language without it, so why do we have any UB at all? We do because of portability and because it gives flexibility to compilers writers. The post is all about whether this flexibility is worth it when compared with the difficulty of writing programs without…

Even stipulating that part of the argument, the author then goes on a tear about optimizations breaking constant-time evaluation, which doesn’t have anything to do with UB. The real argument seems to be that C compilers had it right when they really did embody C as portable assembly, and everything that’s made that mapping less predictable has been a regression.

[deleted]
Post reply on HN