Footguns

Posted Jul 16, 2021 23:42 UTC (Fri) by HelloWorld (guest, #56129)
In reply to: Footguns by khim
Parent article: Rust for Linux redux

There's sigaltstack for that. Or, if that's MS-DOS, cli and sti.

Interesting, I didn't know about that. Anyway, it's a platform-dependent mechanism which isn't guaranteed to be available, and even on Linux it's only used when SA_ONSTACK is used. So I still believe it's reasonable to make that undefined.

Well… the fact that it's a warning says that it's dangerous, but supported thing, isn't it?

That's up to you. If you want, make it -Werror=uninitialized instead.

Better now?

I don't consider it reasonable to make assumptions about how the compiler lays out the memory for local variables. That said, I'll grant you that reasonable people can differ about something like this:

void foo(int *i, int o) {
        i[o] = 42;
}
int bar() {
        int i = 0, j = 0;
        foo(&i, &j - &i);
        return j;
}
int main() {
        printf("%d\n", bar());
}

But I'm not enough of a compiler expert to be able to assess what the performance impact would be if this were allowed. I suspect it would be severe.

Footguns

Posted Jul 17, 2021 0:11 UTC (Sat) by khim (subscriber, #9252) [Link] (3 responses)

> Anyway, it's a platform-dependent mechanism which isn't guaranteed to be available

Seriously? POSIX guarantees it's availability, Windows doesn't need (it doesn't support signals), MS-DOS & embedded are handled with cli/sli (and analogues)… so what kind of “important platform” is in the problem?

> So I still believe it's reasonable to make that undefined.

Maybe, but that's the thing: it works on almost everything. Thus simple rule “things are disallowed if they couldn't ever work” doesn't cover it.

> That's up to you. If you want, make it -Werror=uninitialized instead.

Maybe, but safer option would be to switch to something that doesn't change it's rules every year.

> But I'm not enough of a compiler expert to be able to assess what the performance impact would be if this were allowed. I suspect it would be severe.

Most likely. This would break almost all optimizations based on these “noalias” rules which power a lot of optimizations.

But the story here is: what's the point of something being speedy if said something is no longer correct?

If there were some kind of dialogue between C/C++ compiler developers and users of said compilers then maybe they would have come to an agreement. But there are none.

Footguns

Posted Jul 17, 2021 13:26 UTC (Sat) by HelloWorld (guest, #56129) [Link] (2 responses)

> Seriously? POSIX guarantees it's availability, Windows doesn't need (it doesn't support signals), MS-DOS & embedded are handled with cli/sli (and analogues)… so what kind of “important platform” is in the problem?
As I already mentioned, sigaltstack is only used if you specify SA_ONSTACK. Or that is how I understand the documentation, anyway.

> Maybe, but safer option would be to switch to something that doesn't change it's rules every year.
Sure, most software shouldn't be written in C or C++.

> But the story here is: what's the point of something being speedy if said something is no longer correct?
Well, nobody said writing high performance software was going to be easy. But there are legitimate use cases where you really do want to squeeze every last cycle out of the hardware.

Footguns

Posted Jul 17, 2021 13:49 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

> As I already mentioned, sigaltstack is only used if you specify SA_ONSTACK.

Please read the documentation again. You can not ever set SA_ONSTACK. It's not something you set, but something you can read: sigaltstack couldn't change state of altstack if you are in the middle of a signal handler and said altstack is currently in use!

> But there are legitimate use cases where you really do want to squeeze every last cycle out of the hardware.

But C and C++ are making it harder and harder each year! Because time which is spent making pointless changes which would keep tested and debugging programs working could have been spent on the changes which would make these programs faster instead.

And in wast majority of cases you can get more speedup from doing that. Where new version of compiler can buy you 3% or maybe 5% (if you are lucky) manual tuning can often bring 2x, 3x or even 10x improvements.

And the more artificial constructs you add to your program the slower it becomes.

No wonder that developers of embedded systems where efficiency would be obviously desired typically stick to one version of the compiler (which is not upgraded ever) or, sometimes, even use -O0 to free time for manual optimizations.

Footguns

Posted Jul 17, 2021 14:51 UTC (Sat) by excors (subscriber, #95769) [Link]

> No wonder that developers of embedded systems where efficiency would be obviously desired typically stick to one version of the compiler (which is not upgraded ever) or, sometimes, even use -O0 to free time for manual optimizations.

Based on a majority of the embedded code I've seen, the actual reason is that most embedded software developers are bad software developers. You're lucky if they'll write code that isn't full of obvious buffer overflows, race conditions, etc, and there's almost no chance they'll appreciate concepts like aliasing or memory barriers. That's why it's no surprise their 'tested and debugged' code breaks when they turn on new optimisations - it was only working in the first place by luck and by the very limited extent of their testing. And even when projects are run by competent software developers, they'll probably have to import some third-party libraries (chip SDKs, drivers, etc) which are badly written and/or are precompiled binaries from an ancient compiler version, so they face the same problems.

(To be fair these embedded software developers may have a much better understanding of hardware than the average software developer, which is crucial for doing their job; but they're still bad at software.)