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

GCC 10.1 Released

gcc.gnu.org

Post reply on HN
Print view View original

31–40 of 145 posts

Re: GCC 10.1 Released

#31

Post by legends2k »

qalmakka wrote: post #19
DyslexicAtheist wrote: post #2

I love the built-in static analyzer -fanalyzer option in gcc-10. [1] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...

Isn't it very similar to something Clang has had for years?

Tangential: I think many platforms that GCC supports and the kind of optimisation GCC provides might make it a superior choice for projects. For those developers its exciting. Also if an existing project is using it for a long-time and has not intentions of switching to Clang, for them too this would be interesting.

Re: GCC 10.1 Released

#32

Post by estebank »

simias wrote: post #10
glouwbug wrote: post #7

Earlier quoted context omitted.

Imagine if -fanalyze was like rusts borrow checker

You Rust borrow checker requires special annotations and restrictions put on the code to do its job. I don't think you could something like that automatically on a C or C++ full codebase without having to manually annotate and refactor it somewhat. There are many common (and safe) C and C++ patterns that would be outright rejected by Rust's borrow checker, for instance initializing a structure or array partially if y…

I would dispute that those common patterns are indeed safe, even if they could be argued they are when first written because code changes and can suddenly break your preconditions if they aren't enforced in the code itself.

C codebases then follow certain defensive programming customs to avoid reading uninitialized or out of bounds memory, at the cost of some performance. This is the right trade-off in C but, funnily enough, the more restrictive borrow checker has the opposite effect as you can give out inmutable and mutable references with wanton abandon because they get checked for unsafe behavior. It's the same difference as a a gun where the best practice is to keep it unchambered at all times to avoid the risk of a misfire, and a more modern gun with a safety: it's one more thing to think about but it actually smoothes the operation.

Re: GCC 10.1 Released

#33

Post by mhh__ »

glouwbug wrote: post #7
DyslexicAtheist wrote: post #2

I love the built-in static analyzer -fanalyzer option in gcc-10. [1] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...

Imagine if -fanalyze was like rusts borrow checker

I think Rice's theorem means that you can't really do that without restricting/annotating semantics like Rust does.

Re: GCC 10.1 Released

#34

Post by peapicker »

cornstalks wrote: post #9
htfy96 wrote: post #5

Earlier quoted context omitted.

An example to detect use-after-free: https://godbolt.org/z/zhiNLW Basically this replicates what clang-tidy did

Too bad it doesn't detect the mismatch between new and free.

And if you fix it to use delete instead of free, you get "can't delete void *" errors. Perhaps not the best example code.

Re: GCC 10.1 Released

#35

Post by gpderetta »

peapicker wrote: post #34
cornstalks wrote: post #9

Earlier quoted context omitted.

Too bad it doesn't detect the mismatch between new and free.

And if you fix it to use delete instead of free, you get "can't delete void *" errors. Perhaps not the best example code.

and if you fix the void->int, the warning goes away.

Re: GCC 10.1 Released

#36

Post by verdagon »

pkolaczk wrote: post #13
simias wrote: post #10

Earlier quoted context omitted.

You Rust borrow checker requires special annotations and restrictions put on the code to do its job. I don't think you could something like that automatically on a C or C++ full codebase without having to manually annotate and refactor it somewhat. There are many common (and safe) C and C++ patterns that would be outright rejected by Rust's borrow checker, for instance initializing a structure or array partially if y…

> Rust borrow checker requires special annotations and restrictions put on the code to do its job. This is a good thing, because it makes lifetimes and ownership explicit and visible in the code. It serves the similar purpose as type annotations in function signatures. > Or having multiple mutable pointers/reference to the same object Sure you can have that with `unsafe`. And this is a good thing, because multiple mu…

Can you explain why multiple mutable pointers is bad practice?

I understand the benefits and the risks of them, and understand how Rust prevents both, but I dont yet understand why it's bad practice, and am interested to learn why.

Re: GCC 10.1 Released

#37

Post by rwmj »

DyslexicAtheist wrote: post #2

I love the built-in static analyzer -fanalyzer option in gcc-10. [1] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...

Really? I tried to use it but I got a lot of false positives - in fact, every one of the errors in my medium-sized codebase was I believe a false positive. I spent a few hours last night looking at all of them and while I found a missing free, it was not one picked up by this analysis, but it happened to be in the same code that the analyzer flagged. Also the error messages are enormous in some cases.

It does show potential, and I hope it improves in future. Be nice to have a libre version of coverity one day.

Edit: Output from compiling nbdkit upstream with -fanalyzer: https://paste.centos.org/view/8381f926

Re: GCC 10.1 Released

#38

Post by asveikau »

pkolaczk wrote: post #26
traes wrote: post #16

Earlier quoted context omitted.

He wasn't criticizing Rust, he was just stating facts.

I read it differently, because he started with "You(r) Rust borrow checker", making his point automatically in oposition. But now after reading without this You at the beginning, I agree it was neutral.

My guess is that comment was made on a phone or tablet. It has a lot of small, autocorrect-looking mistakes. Other than the "You", for example there is one part where "initialized" is used where "uninitialized" is clearly intended.

Re: GCC 10.1 Released

#39

Post by CoolGuySteve »

legends2k wrote: post #31
qalmakka wrote: post #19

Earlier quoted context omitted.

Isn't it very similar to something Clang has had for years?

Tangential: I think many platforms that GCC supports and the kind of optimisation GCC provides might make it a superior choice for projects. For those developers its exciting. Also if an existing project is using it for a long-time and has not intentions of switching to Clang, for them too this would be interesting.

My project uses g++ but I’ve been using a clang static-analysis step in my CI pipeline for a while now.

Compiling with clang is much, much slower but it finds interesting errors sometimes. I only had to ifdef out one code section that it couldn’t understand (something about indexing an array with a constexpr function returning an enum class from a template parameter).

It depends on the project, but this one and another project I made work are both 100k lines of C++ and took half a day to setup. It was worth it imo.

Re: GCC 10.1 Released

#40

Post by google234123 »

rwmj wrote: post #37
DyslexicAtheist wrote: post #2

I love the built-in static analyzer -fanalyzer option in gcc-10. [1] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...

Really? I tried to use it but I got a lot of false positives - in fact, every one of the errors in my medium-sized codebase was I believe a false positive. I spent a few hours last night looking at all of them and while I found a missing free, it was not one picked up by this analysis, but it happened to be in the same code that the analyzer flagged. Also the error messages are enormous in some cases. It does show po…

Sadly, that's typical with static analyzers todays...
Post reply on HN