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

51–60 of 145 posts

Re: GCC 10.1 Released

#51

Post by fnord123 »

klodolph wrote: post #25
jcelerier wrote: post #22

Earlier quoted context omitted.

it does not make sense to pair development toolchain versions with operating system versions.

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…

eh, no. the OS package manager is for sysadmins. LTS is for sysadmins to not have to worry about versions changing under their feet rapidly when they apply security updates.

If you want to develop an application, you use your own toolchain. But yes I know most C++ people don't d this because C++ tools don't easily support it. But that's on C++ for not having pyenv, rustup, multiruby, etc equivalent.

Re: GCC 10.1 Released

#52

Post by oconnor663 »

klodolph wrote: post #48
jcelerier wrote: post #27

Earlier quoted context omitted.

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

> Sometimes it turns out that your code relies on some compiler behavior which has changed.

In practice this can be "undefined behavior" like dangling pointers or data races. Maybe the new version of the compiler happens to reorder a couple of instructions (which it's perfectly within it's rights to do) which turns a "benign" race into a crash or an exploitable security issue. Is it your fault for writing these bugs? Sure. But if you're a big organization, and you know you have bugs like this, is this a reason not to upgrade your compiler? Absolutely. All the real world testing you've done on your current binaries has value, and losing some of that value needs to be weighed against the benefits of upgrading.

Re: GCC 10.1 Released

#53

Post by cormacrelf »

verdagon wrote: post #36
pkolaczk wrote: post #13

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.

The one that affects you as a programmer most is Iterator invalidation. Iter borrows from the vector, you mutate the vector, iter blows up. Simple really. But a lot of code is like this. Borrow from hashmap, insert into hashmap, the slot gets moved around and your pointer is now invalid. That’s just vectors and hashmaps; imagine the possibilities in a much more complex data structure.

There are compiler optimisations you can do if compiler knows about aliasing, but that’s not so much a software authorship problem. There are some curly problems with passing aliased mutable pointers to a function written for non-aliased inputs, like memcpy and I imagine quite a lot of other code.

But common to all of these things is that it’s pretty hard to figure out if the programmer is the one who has to track the aliasing. In hashmap pointer invalidation, your code might work perfectly for years until some input comes along and finally triggers a shift or a reallocation at the exact right time. (I know this — I recently had to write a lot of C and these are the kinds of issues you get even after you implement some of Rust’s std APIs in C.)

Re: GCC 10.1 Released

#54

Post by q92z8oeif »

MauranKilom wrote: post #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!

i don't know if you are being ironic or not, but the non-english speaking world will love it.

Re: GCC 10.1 Released

#55

Post by simion314 »

purerandomness wrote: post #42
e12e wrote: post #28

Earlier quoted context omitted.

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?

You might want LTS and upgrade some packages when needed/forced and not play the "update" lottery. New updates not only bring you cool new feature and fixes , they bring new bugs and sometimes features are removed or GUIs are moved around. At least with my LTS I worked around for existing bugs , upgraded from PPA the things I needed to, browsers are latest versions and my IDE is auto-updating too.

Re: GCC 10.1 Released

#57

Post by throwaway894345 »

q92z8oeif wrote: post #54
MauranKilom wrote: post #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!

i don't know if you are being ironic or not, but the non-english speaking world will love it.

There are lots of other languages that support full UTF-8 in identifiers (e.g, Go) and the non-English-speaking world doesn't take advantage.

Re: GCC 10.1 Released

#58

Post by alufers »

q92z8oeif wrote: post #54
MauranKilom wrote: post #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!

i don't know if you are being ironic or not, but the non-english speaking world will love it.

As a non-English programmer who has seen a lot of code not written using English please, god, NO. The mixture of English and other languages identifiers in the external libraries makes me cry.

Re: GCC 10.1 Released

#59

Post by lenkite »

q92z8oeif wrote: post #54
MauranKilom wrote: post #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!

i don't know if you are being ironic or not, but the non-english speaking world will love it.

From a non-english speaking country: I prefer US-ASCII for code. Anything else just obfuscates.

Re: GCC 10.1 Released

#60

Post by zozbot234 »

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…

> for instance initializing a structure or array partially if you're sure that nobody is going to use the initialized portion. Or having multiple mutable pointers/reference to the same object.

Rust supports MaybeUninit for the former example, and unsafe raw pointers for the latter. It needs unsafe because these patterns are not safe in the general case and absent an actual proof of correctness embedded in the source code, a static analysis pass can only deal with the general case.

Post reply on HN