> New function attribute null_terminated_string_arg(PARAM_IDX) for indicating parameters that are expected to be null-terminated strings.
Why is this not a type attribute?
GCC 14.1
21–30 of 55 posts
Re: GCC 14.1
#22> New function attribute null_terminated_string_arg(PARAM_IDX) for indicating parameters that are expected to be null-terminated strings. Why is this not a type attribute?
because most of the time the parameter is going to be a plain char*.
Re: GCC 14.1
#23> New function attribute null_terminated_string_arg(PARAM_IDX) for indicating parameters that are expected to be null-terminated strings. Why is this not a type attribute?
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.
Re: GCC 14.1
#24Earlier 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.
At a certain point, it's probably easier to build and run the unmaintained software in a container running an OS of corresponding vintage. Obviously that has security ramifications, but hopefully this software isn't facing the internet and being in a container at least means you're on a modern kernel and can isolate things at a port and filesystem level.
Debian is super good for this. Most of their apt mirrors are still up and running, so you can easily download and build software from 2002 if you use the appropriate Debian release to do it.
I usually do this first to make sure the software builds and works, then I try to figure out how to get it working on a newer OS.
Re: GCC 14.1
#25It'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).
Looking at those flags, several of them are erroring about things that have been deprecated since before I was born. If you're going to complain that it's breaking old code, I have to ask why this code is simultaneously important enough to you to use a modern compiler with modern flags to build it and not important enough to bother changing for 30 years.
Re: GCC 14.1
#26It'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'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.
Re: GCC 14.1
#27Earlier 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.
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 strings. I haven't looked into this new feature, but I assume that's what it's doing.
If you mean why is the "__attribute__" syntax not declaring such a thing adjacent to the function, the answer is that this allows for shoving the . extended syntax into standard C in a mostly backwards compatible way.
Re: GCC 14.1
#28Is Ada being used in the industry? Looks actually quite fun to play with from changelog additions. I didn’t realise it’s still under active development.
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.
Re: GCC 14.1
#29It'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).
Good. Long overdue.
Re: GCC 14.1
#30Earlier quoted context omitted.
This is true but by now distros have fixed most of the breakage and sent the changes back upstream (certainly this is true for Fedora).
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.