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

391–400 of 405 posts

Re: Clang vs. Clang

#391

Post by pritambaral »

RandomThoughts3 wrote: post #111
pritambaral wrote: post #83

Earlier quoted context omitted.

> There is a whole stack of systems to prevent that from ever happening. You've almost got the point your parent is trying to make. That the supply chain shares this responsibility, as they said. > I would like to know by which magic you think a CRUD app could burn a battery? I don't know about batteries, but there was a time when Dell refused to honour their warranty on their Inspiron series laptops if they found VL…

> You've almost got the point your parent is trying to make. That the supply chain shares this responsibility, as they said. Deeply disagree. Failsafe doesn’t magically remove your responsibility. I’m so glad I started my career in a safety critical environment with other engineers working on the non software part. The amount of software people who think they can somehow absolve themselves of all responsibility for s…

>> ... shares this responsibility

> Deeply disagree. ... doesn't magically remove your responsibility.

??

Literally no-one in this thread is talking about "removing responsibility", except you.

> I'm so glad ... in the field.

I don't know which demon you're trying beat back here, nor why.

> It's Dell's fault - not ...

That it is Dell's fault is not under question, but it also does not automatically absolve the speaker manufacturer or the subcontractor. Hold on, isn't that exactly the drum you've been trying to beat here?

You and I have no idea what actually went down. Maybe the speaker was wrongly rated as being able to take a higher current than it actually could. Or maybe there was a bug in the driver. Either would make someone other than Dell also responsible for the failure.

And that's what we've been trying to tell you. That responsibility is shared.

Re: Clang vs. Clang

#392

Post by atiedebee »

thayne wrote: post #130
layer8 wrote: post #69

Earlier quoted context omitted.

It’s true that UB is not intuitive at first, but “ridiculous amount” and “difficult to avoid” is overstating it. You have to have a proof-writing mindset when coding, but you do get sensitized to the pitfalls once you read up on what the language constructs actually guarantee (and don’t guarantee), and it’s not that much more difficult than, say, avoiding panics in Rust.

It isn't so much that it is unintuitive, for the most part[1], but rather that there are a lot of things to keep track of, and a seemingly innocous change in one part of the program can potentially result in UB in somewhere far away. And usually such bugs are not code that is blatantly undefined behavior, but rather code that is well defined most of the time, but in some edge case can trigger undefined behavior. It w…

I think the reason that signed integer overflow is undefined is that it wasn't uncommon at the time to have architectures that didn't represent signed integers with 2's complement.

Even today you may find issues with signed integers. The ESP32 vector extensions seem to saturate signed integer overflow [1].

[1]: https://bitbanksoftware.blogspot.com/2024/01/surprise-esp32-...

Re: Clang vs. Clang

#393

Post by hedgehog »

account42 wrote: post #389
hedgehog wrote: post #386

Earlier quoted context omitted.

That argument would make more sense if such a language was widely available but today in practice it isn't so we live in the universe of less ideal solutions. Actually it doesn't really respond to DJB's point anyway, his case here is that the downstream labor cost of compiler churn exceeds the actual return in performance gains from new features and that a change in policy could give security-related code a more pred…

> his case here is that the downstream labor cost of compiler churn exceeds the actual return in performance gains from new features Yes but his examples are about churn in code that makes assumptions that neither the language nor the compiler guarantees. It's not at all surprising that if your code depends on coincidental properties of your compiler that compiler upgrades might break it. You can't build your code on…

I think this attitude is what is driving his complaints. Most engineering work exists in the context of towering teetering piles of legacy decisions, organizational cultures, partially specified problems, and uncertainty about the future. Put another way "the implementation is the spec" and "everything is a remodel" are better mental models than spec-lawyering. I agree that relying on say stability of the common set of compiler optimizations circa 2015 is a terrible solution but I'm not convinced it's the wrong one in the short term. Are we really getting enough perf out of the work to justify the complexity? I don't know. It's also completely infeasible given the incentives at play, complexity and bugs are mostly externalities that with some delay burden users and customers.

Personally I'm grateful the cryptographers do what they do, computers would be a lot less useful without their work.

Re: Clang vs. Clang

#394

Post by atiedebee »

account42 wrote: post #371
celrod wrote: post #253

Earlier quoted context omitted.

Signed integer overflow being undefined has these two consequences for me: 1. It makes my code slightly faster. 2. It makes my code slightly smaller. 3. It makes my code easier to check for correctness, and thus makes it easier to write correct code. Win, win, win. Signed integer overflow would be a bug in my code. As I do not write my own implementations to correctly handle the case of signed integer overflow, the c…

Agreed. If anything, I'd like to have an unsigned type with undefined overflow so that I can get these benefits while also guaranteeing that the numbers are never negative where that doesn't make any sense.

That's what zig did, and they solved the overflow problem by having seperate operators for addition and subtraction that guarantee that the number saturates/wraps on overflow.

Re: Clang vs. Clang

#395

Post by atiedebee »

kzrdude wrote: post #270
bhk wrote: post #98

Earlier quoted context omitted.

There's an important point to be made here: those who define the semantics of C and C++ shovel an unreasonable amount of behavior into the bucket of "undefined behavior". Much of this has dubious justifications, while making it more difficult to write correct programs.

For example the recent realloc change in C23. I was surprised the previously used behaviour, even if inconsistent across implementations, was declared UB. Why not impdef?

Agreed, C23 screwed over a lot of backwards compatibility

Re: Clang vs. Clang

#396

Post by saagarjha »

tsimionescu wrote: post #362
saagarjha wrote: post #360

Earlier quoted context omitted.

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 mem…

The C standard definitely has opinions on races

Re: Clang vs. Clang

#397

Post by GTP »

atiedebee wrote: post #390
GTP wrote: post #248

Earlier quoted context omitted.

It's not even that. Yes, in case of signed intger overflow, usually yoj get whatever the CPU gives as answer for the sum. But you also have the famous case of an if branch checking for a null pointer being optimized away. And even in the case of integer overflow, the way to correctly check for it isn't intuitive at first, because you need to check for integer overflow without the check itsef falling under UB. EDIT: j…

When do NULL checks get optimised away, apart from the case where the pointer has already been accessed/is known at compile time to be invalid?

I couldn't find again the example I saw many years ago, I could only find a GCC bug that has been fixed now. So you're likely right and I just didn't remember correctly. But we still can have the zeroing out of memory before deallocation that can get silently optimized away. Maybe also naive attempts at checking for signed integer overflow could be silently optimized away. My general point is that, if the compiler determines that the code has dead instructions/unneded checks, it is very likely that the programmer's mental model of the code is wrong. So, just like the case of using an integer as a pointer or vice versa, we should have a warning telling the programmers that some code is going to not be compiled. Also in the case of the null pointer check: this would make the programmer realize that the check is happening too late and should instead be performed earlier

Re: Clang vs. Clang

#398

Post by deaddodo »

tsimionescu wrote: post #351
deaddodo wrote: post #344

Earlier quoted context omitted.

> This is dead wrong, and a very dangerous mindset. It's "dead wrong" that compilers independently choose to define undefined behavior? Oh, ok; I guess I must just be a stellar programmer to never have received the dreaded "this is undefined" error (or it's equivalent) that would inevitably be emitted in these cases then.

I've explained and showed an example of how compilers behave in relation to UB. They don't typically "choose to define it", they choose to assume that it never happens. They don't throw errors when UB happens, they compile your program under the assumption that any path that would definitely lead to UB can't happen at runtime. I believe you think that because signed integer addition gets compiled to the `add` instruc…

No, I said it had consistent behavior to the compiler.

You seem to think I'm saying "undefined behavior means nothing, ignore it"; when what I'm actually saying is "undefined behavior doesn't mean the compiler hasn't defined a behavior and doesn't necessarily = 'bad'". There's dozens of "UB" that C (and C++) developers rely on frequently, because the compilers have defined some behavior they follow; to the point critical portions of the Linux Kernel rely on it (particularly in the form of pointer manipulations).

TL;DR - Is UB unsafe to rely on generally? Yes. Should you ignore UB warnings? Definitely not. Does UB mean that the compiler has no idea what to do or is lacking some consistent behavior? Also, no.

Know your compiler, and only write code that you know what it does; especially if it's in a murky area like "UB".

Re: Clang vs. Clang

#399

Post by andrewaylett »

gavinhoward wrote: post #321
andrewaylett wrote: post #300

Earlier quoted context omitted.

If you want a programming language without undefined behaviour, you want something that's not C .

Correct. Which is why I made my own. But C is still better than other languages because it is small.

It looks small, but it's not really -- the C abstract machine differs too much from the actual hardware it's running on.

You could write a "CVM", akin to the JVM, that runs C code in a virtual environment that matches the abstract machine. Or you can let your compiler deal with the differences, which leads to unhappiness such as is exhibited in this discussion thread and the article it's discussing.

Re: Clang vs. Clang

#400

Post by shrimp_emoji »

mgaunard wrote: post #381
brabel wrote: post #357

Earlier quoted context omitted.

Google hires the best developers in the world. They pay well beyond anyone else except the other big SV tech giants, who compete for the best. I don't work for them but if money was my main motivator and they had jobs not too far from me I would totally want to. My point is: don't pretend you're superior to them. You're very likely not, and even if you are really good, they're still about the same level as you. If yo…

Ignoring the fact this isn't even true, you're completely misunderstanding my point. As I said, Google does not prioritize for technical expertise, primarily because that's quite individual-centric. They're a large organization and their goal is to make sure people are formatted and replaceable. They hire generally smart people and mold them to solve problems with the frameworks that they've previously built, with gu…

> their goal is to make sure people are formatted and replaceable.

Why else would corporations be the exclusive authors of "middle-level" languages like Java, C#, and Go? ;p JS and Python are too slow, but we can't find enough C, C++, or Rust developers! Let's invent these abominations instead with which we can churn out more good-enough mediocrity per quarter than ever before!

Post reply on HN