Live data from Hacker News

GCC 10.1 Released

gcc.gnu.org

41–50 of 145 posts

Re: GCC 10.1 Released

#41
post #37

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…

Looking at the categories of warnings it produces, I'm not surprised. When I've used similar tools trying to detect the same things, I also saw false positives. It's probably not an easy set of problems, otherwise we'd have it built-in to more tools and enabled by default.

Re: GCC 10.1 Released

#42
post #28
post #14

Earlier quoted context omitted.

If you want the newest version of software, Ubuntu does not cater to that.

Well, you might want to run a newer/non-lts release via lxd/lxc. It's probably a much better idea than pulling in willy-nilly ppa's.

But at this point, why not simply run Arch Linux?

Re: GCC 10.1 Released

#43
post #37

Earlier quoted context omitted.

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…

Looking at the categories of warnings it produces, I'm not surprised. When I've used similar tools trying to detect the same things, I also saw false positives. It's probably not an easy set of problems, otherwise we'd have it built-in to more tools and enabled by default.

We routinely run nbdkit through Coverity and it finds bugs, although it too has false positives. Also the reports produced by Coverity are really nice - long enough to tell you where the bug is, but not too long to be overwhelming.

I've been meaning to formally prove one of our internal "mini libraries" using Frama-C. If we did that then no one would be able to complain about bugs in it :-)

Re: GCC 10.1 Released

#45

Earlier quoted context omitted.

What do you think LTS entails, exactly? One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary. If you want the latest GCC, that's fine, you're not forced to use the default compiler distributed with your OS. But it doesn't make sense to update the default compiler used in an LTS release. I…

> One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary. Yes, and updating compilers don't prevent that at all. You can use GCC 10 to ship code that will build and run on Ubuntu 12.04 without issues. Xcode 11 can ship code that works back to macOS 10.6 and Visual Studio 2019 can still opti…

> Yes, and updating compilers don't prevent that at all.

You do understand that ABI backward compabitility is not ensured, don't you?

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Some software packages even break between distro releases.

The primary value of a distro is to provide a fixed platform that application developers and users can safely target. Risking ABI breakups just because a rare number of users wish to be on the bleeding edge without wanting to do any of the work to install their own software is something that's very hard to justify.

Re: GCC 10.1 Released

#46
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…

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…

I'd describe the pattern in slightly different terms: when done right, restrictions in a programming language (or library/framework) are liberating for the programmer.

The restriction of immutability spares the programmer from worrying about whether unknown parts of the codebase are going to decide to mutate an object.

JavaScript's single-thread restriction (not counting web-workers) closes the door on all manner of nasty concurrent-programming problems that can arise in languages that promote overuse of threads. (Last I checked, NetBeans uses over 20 threads.)

Back to the example at hand, C has no restrictions, but that hobbles the programmer when it comes to reasoning about the way memory is handled in a program. It's completely free-form. Rust takes a more restrictive approach, and even enables automated reasoning. (Disclaimer: I don't know much about Rust.)

Re: GCC 10.1 Released

#47
> Extended characters in identifiers may now be specified directly in the input encoding (UTF-8, by default), in addition to the UCN syntax (\uNNNN or \UNNNNNNNN) that is already supported:

    static const int π = 3;
    int get_naïve_pi() {
      return π;
    }
Lovely!

Re: GCC 10.1 Released

#48

Earlier quoted context omitted.

What do you think LTS entails, exactly? One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary. If you want the latest GCC, that's fine, you're not forced to use the default compiler distributed with your OS. But it doesn't make sense to update the default compiler used in an LTS release. I…

> One of the core ideas of working with LTS is that you can build your software on an LTS release and ship it to somebody else on the same LTS release, either as a source or as a binary. Yes, and updating compilers don't prevent that at all. You can use GCC 10 to ship code that will build and run on Ubuntu 12.04 without issues. Xcode 11 can ship code that works back to macOS 10.6 and Visual Studio 2019 can still opti…

> [...] and updating compilers don't prevent that at all.

This is incorrect. In practice, for larger code bases, upgrading to a newer version of GCC or Clang is something that must be done purposefully, and you must test.

Sometimes it turns out that your code relies on some compiler behavior which has changed. Sometimes newer compilers are stricter than older compilers. There are plenty of real-world cases of these problems!

> Xcode 11 can ship code that works back to macOS 10.6 [...]

There are a number of features that are specific to the macOS toolchain which make this possible. Take a look at the "-mmacosx-version-min" flag on the macOS compiler. This selectively enables and disables various APIs. These features don't solve all the compatibility problems, either.

> Visual Studio 2019 can still optionally target windows fucking XP !

We're talking about Linux here. The Windows toolchain is radically different.

Re: GCC 10.1 Released

#49

Earlier quoted context omitted.

> 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.

Because it leads to hard to understand code.

If N unrelated (or loosely related) things can mutate the same object, then you get a O(x^N) explosion of potential mutation orders and in order to understand that, you need to understand all the (sometimes complex) time-relationships between these N objects. This gets even much worse when some of these objects are also pointed from M other objects...

On the flip side, in case of using a simple unique_ptr (or a similar concept), this trivially reduces to a single sequence of modifications.

Re: GCC 10.1 Released

#50
post #7

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

No need to imagine, It's becoming reality -> https://internals.rust-lang.org/t/c-lifetime-profile-1-0-a-k...
Post reply on HN