Most active commenters
  • pjmlp(4)
  • uecker(3)

←back to thread

GCC 15.1

(gcc.gnu.org)
270 points jrepinc | 19 comments | 25 Apr 25 10:53 UTC | HN request time: 0.651s | source | bottom
Show context
Calavar ◴[25 Apr 25 12:39 UTC] No.43792948[source]▶
> {0} initializer in C or C++ for unions no longer guarantees clearing of the whole union (except for static storage duration initialization), it just initializes the first union member to zero. If initialization of the whole union including padding bits is desirable, use {} (valid in C23 or C++) or use -fzero-init-padding-bits=unions option to restore old GCC behavior.

This is going to silently break so much existing code, especially union based type punning in C code. {0} used to guarantee full zeroing and {} did not, and step by step we've flipped the situation to the reverse. The only sensible thing, in terms of not breaking old code, would be to have both {0} and {} zero initialize the whole union.

I'm sure this change was discussed in depth on the mailing list, but it's absolutely mind boggling to me

replies(14): >>43793036 #>>43793080 #>>43793121 #>>43793150 #>>43793166 #>>43794045 #>>43794558 #>>43796460 #>>43798312 #>>43798826 #>>43800132 #>>43800234 #>>43800932 #>>43800975 #
1. VyseofArcadia ◴[25 Apr 25 12:50 UTC] No.43793036[source]▶
I feel like once a language is standardized (or reaches 1.0), that's it. You're done. No more changes. You wanna make improvements? Try out some new ideas? Fine, do that in a new language.

I can deal with the footguns if they aren't cheekily mutating over the years. I feel like in C++ especially we barely have the time to come to terms with the unintended consequences of the previous language revision before the next one drops a whole new load of them on us.

replies(7): >>43793065 #>>43793137 #>>43793145 #>>43793417 #>>43793448 #>>43793509 #>>43793850 #
2. ryao ◴[25 Apr 25 12:55 UTC] No.43793065[source]▶
I suspect this change was motivated by standards conformance.
replies(1): >>43793169 #
3. seritools ◴[25 Apr 25 13:03 UTC] No.43793137[source]▶
> If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behavior was undefined, but commonly implemented this way.

https://en.cppreference.com/w/c/language/union

> When initializing a union, the initializer list must have only one member, which initializes the first member of the union unless a designated initializer is used(since C99).

https://en.cppreference.com/w/c/language/struct_initializati...

→ = {0} initializes the first union variant, and bytes outside of that first variant are unspecified. Seems like GCC 15.1 follows the 26 year old standard correctly. (not sure how much has changed from C89 here)

4. hulitu ◴[25 Apr 25 13:03 UTC] No.43793145[source]▶
It's careless development. Why think something in advance when you can fix it later. It works so well for Microsoft, Google and lately Apple. /s

The release cycle of a software speaks a lot about its quality. Move fast, break things has become the new development process.

replies(1): >>43802151 #
5. fuhsnn ◴[25 Apr 25 13:06 UTC] No.43793169[source]▶
The wording of GCC maintainer was "the standard doesn't require it." when they informed Linux kernel mailing list.

https://lore.kernel.org/linux-toolchains/Z0hRrrNU3Q+ro2T7@tu...

replies(1): >>43793842 #
6. ◴[25 Apr 25 13:35 UTC] No.43793417[source]▶
7. pjmlp ◴[25 Apr 25 13:38 UTC] No.43793448[source]▶
Programming languages are products, that is like saying you want to keep using vi 1.0.

Maybe C should have stop at K&R C from UNIX V6, at least that would have spared the world in having it being adopted outside UNIX.

replies(2): >>43793673 #>>43794562 #
8. _joel ◴[25 Apr 25 13:45 UTC] No.43793509[source]▶
Perl 6 and Python 3 joined the chat
9. rgoulter ◴[25 Apr 25 14:03 UTC] No.43793673[source]▶
I liked the idea I heard: internet audiences demand progress, but internet audiences hate change.
10. matheusmoreira ◴[25 Apr 25 14:18 UTC] No.43793842{3}[source]▶
Reminds me of strict aliasing. Same attitude...

https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing/

11. Ragnarork ◴[25 Apr 25 14:19 UTC] No.43793850[source]▶
> I feel like once a language is standardized (or reaches 1.0), that's it. You're done. No more changes. You wanna make improvements? Try out some new ideas? Fine, do that in a new language.

Thank goodness this is not how the software world works overall. I'm not sure you understand the implications of what you ask for.

> if they aren't cheekily mutating over the years

You're complaining about languages mutating, then mention C++ which has added stuff but maintained backwards compatibility over the course of many standards (aside from a few hiccups like auto_ptr, which was also short lived), with a high aversion to modifying existing stuff.

12. ryao ◴[25 Apr 25 15:24 UTC] No.43794562[source]▶
If C++ had never been invented, that might have been the case.
replies(1): >>43795609 #
13. pjmlp ◴[25 Apr 25 16:33 UTC] No.43795609{3}[source]▶
C++ was invented exactly because Bjarne Stroustoup vouched never again to repeat the downgrade of his development experience from Simula to BCPL.

When faced with writing a distributed systems application at Bell Labs, and having to deal with C, the very first step was to create C with Classes.

Also had C++ not been invented, or C gone into an history footnote, so what, there would be other programming languages to chose from.

Lets not put programming languages into some kind of worshiping sanctuary.

replies(1): >>43801764 #
14. uecker ◴[26 Apr 25 08:03 UTC] No.43801764{4}[source]▶
I don't think C would have become a footnote if not for C++ given UNIX.
replies(1): >>43802104 #
15. pjmlp ◴[26 Apr 25 09:24 UTC] No.43802104{5}[source]▶
Most likely C++ would not happened, while at the same time C and UNIX adoption would never gotten big enough to be relevant outside Bell Labs.

Which then again, isn't that much of a deal, industry would have steered into other programming languages and operating systems.

Overall that would be a much preferable alternative timeline, assuming security would be taken more seriously, as it has taken 45 years since C.A.R Hoare Turing award speech and Morris worm, and only after companies and government started to feel the monetary pain of their decisions.

replies(1): >>43804227 #
16. pasc1878 ◴[26 Apr 25 09:33 UTC] No.43802151[source]▶
That does not make sense for anything that exists over decades.

Do you want to be still using Windows NT, or C++ pred 2004 standard or python 2.0

We learn more and need to add to things., Some things we designed 30 years ago were a mistake should we stick with them.

You can't design everything before release for much software. Games you can or bespoke software for a business as you can define what it does, but then the business changes.

17. uecker ◴[26 Apr 25 15:02 UTC] No.43804227{6}[source]▶
I think there are very good reasons why C and UNIX were successful and are still around as foundational technologies. Nor do I think C or UNIX legacy are the real problem we have with security. Instead, complexity is the problem.
replies(1): >>43805210 #
18. pjmlp ◴[26 Apr 25 16:54 UTC] No.43805210{7}[source]▶
Starting by being available for free with source code tapes, and a commented source code book.

History would certainly have taken a different path when AT&T was allowed to profit from Bell Labs work, as their attempts to later regain control from UNIX prove.

Unfortunately that seems the majority opinion on WG14, only changed thanks to government and industry pressure.

replies(1): >>43805996 #
19. uecker ◴[26 Apr 25 18:29 UTC] No.43805996{8}[source]▶
Being free was important and history could have taken many paths, but this does not explain why it is still important today and has not been replaced despite many alternatives. WG14 consists mostly of industry representatives.