GCC 14.1
gcc.gnu.org
gcc.gnu.org
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).
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.
Futher more every warning Explains why the std value affects them.
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.
CFront wasn't C, nor Objective-C was C, even though both originally started as macro preprocessors targeting C code generation, and were like Typescript for C.
They became their own thing, after enough user based was won, and nowadays all major C compilers and standard libraries are written in C++, not C.
You must be very young.
Breaking compilation is not a sign of maturity. See Rust for details.
C is over 50 years old.
Python is 30.
Haskell 35
Java 30
As per my own experiences so far, we maintain an older version of GCC for matching GBA decompilation projects, which exhibits compilation errors now.
Presumably they can then be disabled when needed yes? Sounds like a better default.
> 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.
Ada is assumed to be dead by most US-centric programmers, but is alive and used outside the US. Seems most of the action these days in Ada-land is in Europe.
I don't think extensions are a "mess", certainly they're much less of a mess than x86 (a low bar, I know ...)
Most remarkable is the mention of issues around C. This got extensive discussion. It turned out only Qualcomm has issues, and the rest of companies with large scale implementations are happy with C.
It was proven in these discussions that the issues Qualcomm brought up are specific to their implementation largely reusing the ARM core they obtained from Nuvia acquisition, and easy to avoid with a clean board implementation.
The board ultimately ruled against Qualcomm's proposal[0], and the world moved on. Note that every purchasable chip out there supports C, and this is unlikely to change.
It makes more sense if you think about it like programming libraries. That's the same 'mess', but it's not a problem.
There is often fear of 'fragmentation', but vendors tend to be highly responsive to their target market and competitors for each application and will coalesce around a set of extensions that make sense.
The other thing I'd add is that the one thing worse than having 'yet another extension' is not having the extension you need. Extensions are a response to market demand.
Note that all software compiled for RVA20 does still run on RVA22 CPUs. but software built for RVA22 does not (directly, trapping and emulating is possible) run on the older RVA20 CPUs, as they lack the necessary instructions.
This is not unlike e.g.: x86-64v3 vs x86-64v2.
It is only in situations where the implementation is very small and vendor has full control of both the software and the hardware stack that the vendor might benefit from implementing exactly what they want.
CPUs and software stacks for servers, workstations, laptops, smartphones, tablets and such simply stick to profiles.
Windows and Android are expected to require RVA22+V, possibly RVA23, as the baseline.
Even weirder that this one got swept under the changelog rug, it's a pretty major issue.
Why is this not a type attribute?
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.
__attribute__((null_terminated)) const char* x = strcpy(maybe_not_null_terminated, “some string”);
void do_something(__attribute__((null_terminated)) char* f);