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

11–20 of 145 posts

Re: GCC 10.1 Released

#11

Post by DyslexicAtheist »

ufo wrote: post #3
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...

What do you love the most about the new analyzer pass? I haven't had a chance to try it out for myself yet but I'm looking forward to it.

I like not having to run another commercial tool[1] that will likely not be in use whenever I move on to the next project because no one has heard of it.

Biggest advantage I see is it's integrated into the compiler and so sees the same things the compiler does.

Having gcc do this out of the box helps people port their experience/skills with static analysis to other companies.

We already have clang-tidy and I like it too but it's nice to have a fall-back to compare when one produces a strange result. And a bit of competition is always good to have between such projects. And on most big projects it's not like you can just change the build system to use another compiler.

Also I found some interesting cases which valgrind didn't see because it was in an unreachable branch.

[1] https://news.ycombinator.com/item?id=22712338

Re: GCC 10.1 Released

#13

Post by pkolaczk »

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…

> 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 mutable pointers to the same object is at best bad coding practice that leads to unsafe code, and you should avoid that in any language, including the ones with GC. Working with codebases where there are multiple distant things mutating shared stuff is a terrible experience.

If a C/C++ version of "borrow checker" could mark such (anti)patterns at least as warnings, that would bring a lot of value.

Re: GCC 10.1 Released

#16

Post by traes »

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…

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

Re: GCC 10.1 Released

#17

Post by simias »

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…

> Sure you can have that with `unsafe`

The parent was talking about the borrow checker so I only was talking about safe Rust code. Obviously if you consider that the entire C/C++ codebase is in a big unsafe {} block it'll work... because it won't do anything at all.

Post reply on HN