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

GCC 14.1

gcc.gnu.org

Post reply on HN
Print view View original

31–40 of 55 posts

Re: GCC 14.1

#31

Post by PKop »

mid-kid wrote: post #8

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).

>enables a few -Werror flags by default

Presumably they can then be disabled when needed yes? Sounds like a better default.

Re: GCC 14.1

#32

Post by vlovich123 »

avar wrote: post #27
vlovich123 wrote: post #23

Earlier quoted context omitted.

They’re asking why it’s not an attribute on the type instead of on the function. I don’t believe your answer explains that unless I’m overlooking some obvious implication of your statement.

For reasons that are too hairy to go into here C doesn't "really" have a string type (yeah, yeah pendants, I know about fixed strings etc.). It just has arrays of char, which you pinky promise will end in a \0 for things that expect strings. By declaring that yes, this function really must have that terminating \0 a sufficiently smart compiler can statically analyze some errant use of functions expecting terminated s…

No, I’m asking why you can’t apply this variable on types within a function to verify that for example:

    __attribute__((null_terminated)) const char* x = strcpy(maybe_not_null_terminated, “some string”);
Is a warning. Similarly, if it’s a type attribute then you’d apply it on the argument itself instead of needing to specify it on the function + an IDX parameter:

    void do_something(__attribute__((null_terminated)) char* f);
The newly introduced strub attribute works this way, so it’s unclear why a function attribute was chosen for this attribute instead of a type attribute.

Re: GCC 14.1

#33

Post by ropejumper »

Jtsummers wrote: post #28
ropejumper wrote: post #10

Earlier quoted context omitted.

It's pretty famously used by the US government for safety-critical software.

It was created by the US government, or at least by committee for the US government, specifically the DOD. There was a DOD mandate to use Ada, that lasted about 5 minutes before the rebellion against it won out. There's not a lot of new (this century) software written at the DOD's request in Ada.

That's interesting. For some reason I imagined it's still a requirement now.

Re: GCC 14.1

#34

Post by pjmlp »

ho_schi wrote: post #26
emidln wrote: post #19

Earlier quoted context omitted.

It's great seeing progress made here. C/C++ will never be truly safe languages, but every little bit the compiler can help with is appreciated, esp by those maintaining established codebases.

CPP2/cppfront: https://github.com/hsutter/cppfront I hope we see this in C++26 as optional mode i.e. #safe and #unsafe and same for #impdef or so.

It is only yet another wannabe C++ replacement, regardless how it is sold as not being one.

Re: GCC 14.1

#35

Post by Phyx »

cozzyd wrote: post #30
mid-kid wrote: post #12

Earlier quoted context omitted.

Well, yeah, for maintained upstreams. I sometimes need to build older versions of software and simply use unmaintained software, for which these changes are a bit of a pain, along with -fno-common before it.

it would be nice if they provided a gcc-ancient-compat or something though it's easy enough to create an alias with the correct flags.

-std=gnu98 works. ie explicitly telling it your code is not modern C.

Re: GCC 14.1

#36

Post by fl0ki »

mid-kid wrote: post #8

It's worth noting that this release breaks a lot of older code, see: https://wiki.gentoo.org/wiki/Modern_C_porting#What_changed.3... It enables a few -Werror flags by default, refusing to compile code with probable undefined behavior. Unfortunately, a lot of older code subtly raises these warnings (now hard errors), even in cases where it's "fine" (due to valid platform assumptions).

It says a lot that this document has to include things like this:

> Only cast if confident it's correct, otherwise investigate more. Casts will silence real problems if incorrectly used.

> Do not assume it is supposed to be an int.

> Do not simply cast to the "other side" of the error. Casts will silence warnings/errors, but that does not mean the cast is correct.

Besides the increasingly well-known footguns of old C code, we're always going to have problems if there isn't an inherent safety culture among the people maintaining open source projects, whether as upstream or a distributor.

Re: GCC 14.1

#38

Post by gpderetta »

vlovich123 wrote: post #23
gpderetta wrote: post #22

Earlier quoted context omitted.

because most of the time the parameter is going to be a plain char*.

They’re asking why it’s not an attribute on the type instead of on the function. I don’t believe your answer explains that unless I’m overlooking some obvious implication of your statement.

Oh, I see you want to annotate the parameter in the type position, so the annotation act as some sort of qualifier.

Re: GCC 14.1

#40

Post by ho_schi »

pjmlp wrote: post #34
ho_schi wrote: post #26

Earlier quoted context omitted.

CPP2/cppfront: https://github.com/hsutter/cppfront I hope we see this in C++26 as optional mode i.e. #safe and #unsafe and same for #impdef or so.

It is only yet another wannabe C++ replacement, regardless how it is sold as not being one.

A wannabe replacement by…Herb Sutter. I dare to differ.
Post reply on HN