Porting to GCC 14: C language issues

https://gcc.gnu.org/gcc-14/porting_to.html#c

by fweimer • 2 years ago

154 136 2 years ago

gcc.gnu.org

actionfromafar4• 2 years ago

I like how delightfully stable GCC and C is when things from C99 is mandatory only now, a quarter of a century later.

haolez• 2 years ago

Didn't some parts of C99 get rolled back on C11 and other newer ones?

fl0ki3• 2 years ago

Variable Length Arrays were mandatory in C99, optional in C11, and are mandatory again in C23.

I'm curious how these dynamics play out in less popular compilers. If a compiler implemented VLAs in C99, they almost certainly still have that feature for backwards compatibility even after they support C11.

Is there any compiler which appeared on the scene between C11 and C23, and during that window, chose not to support VLAs and thus C99? It's not like C11 itself was very widely adopted, precisely because of the long implementation and industry rollout windows.

fl0ki3• 2 years ago

And still not even mandatory if you use -fpermissive or -std=c89.

I don't envy how much tech debt they have to deal with, while still trying to make it possible for new code to have a more modern experience. For all the excitement around new languages, we're still going to have a lot of C code for a long time, and difficult work like this should be appreciated.

estebank2• 2 years ago

I can't help but wonder how many bugs could have been detected and fixed a quarter of a century earlier if those lints had been adopted more diligently by the C ecosystem.

loeg2• 2 years ago

My perception is that more and better warnings, and common use of -Wall, came into vogue around the time of GCC 4, in the mid 2000s. It would have been pretty abrupt to immediately enforce C99 in 1999-2000.

spookie• 2 years ago

The other day I tried to compile a really old program, the Power Crust and its predecessor. It just worked, for some reason I was expecting it not to. I didn't even have the filetype it was supposed to accept, but it was fine, it was just a list of points. One per line.

Sanity is such a rare thing these days.

lelanthran• 2 years ago

I like how delightfully stable GCC and C is when things from C99 is mandatory only now, a quarter of a century later.

This is how stable it is - they were still supporting C constructs from prior to C89 standardisation (which is when, I believe, void pointers were introduced).

"maybe consider using void * in more places (particularly for old programs that predate the introduction of void * into the C language). "

rwmj2• 2 years ago

We've done the work for Fedora now. There was a long thread on the subject at the beginning of the effort which is interesting: https://lists.fedoraproject.org/archives/list/devel@lists.fe...

veltas5• 2 years ago

As someone who doesn't know a lot about distro work, what exactly did you have to do for Fedora? Fix packages that weren't building anymore with this change?

cozzyd• 2 years ago

As I understand it, the main problem is autoconf-generated stuff with old versions of autoconf.

fweimer3• 2 years ago

Packages fail to build after a while all the time. The maintainer fixes them (preferably using an upstream patch), and we move on.

The issue with this set of compiler changes was that a lot of software builds successfully, but the new build suddenly has expected features missing. This happened with the previous attempt:

https://lists.fedoraproject.org/archives/list/devel@lists.fe...

That happened in 2016. In 2019, we undertook another attempt, this time with config.log/config.h diffing, but for various reasons stopped after fixing a few dozen packages, so it never went to the Fedora/upstream proposal stage.

After Xcode and Clang the changed the defaults, it was somewhat easier to convince people that we should get Fedora & upstreams ready for a future GCC change. It also helped that Gentoo has been pushing fixes for Clang compatibility upstream for a while (https://bugs.gentoo.org/408963, with a broader scope in https://bugs.gentoo.org/870412).

Joker_vD11• 2 years ago

It is no longer possible to call a function that has not been declared.

Heh. Surprisingly, I've seen some people claiming that it's impossible for a language without forward declarations to have a one-pass compiler that could handle calls of not-yet-defined functions, yet pre-ANSI C managed to do exactly that, in a pretty obvious (now that you know that it's in fact possible) way.

jcranmer2• 2 years ago

But prototype-less functions in C don't actually work all that well. In particular, the inferred return type is going to be an int, so if you're trying to return a 64-bit pointer via a prototype-less function, you're going to have a very bad time.

Joker_vD11• 2 years ago

Yes, they don't; it would be possible for a compiler to gather info about such call sites into a list and then, when it's finished compiling a compilation unit, to check this list against the now-complete symbol table and fail if some called functions have mismatched definitions or are still undefined... that's apparently was too much work back when C was designed so we have "hope for the best" design instead.

Karellen3• 2 years ago

Well, there is an argument to be had that, for C, a plain unadorned "int" should probably be the native word size for that architecture. On 64-bit systems, "int" would therefore also be 64 bits.

bewaretheirs2• 2 years ago

Historically they worked well enough (on 16-bit and 32-bit machines) because sizeof(pointer) == sizeof(int) == sizeof(general register) on the architectures where C flourished in the pre-ANSI C era.

But with the migration to 64-bit machines, typically int stayed put at 32 bits.

I guess nobody wanted to introduce a new integral type between short and int; they had enough trouble dealing with code which assumed sizeof(long) == 4. I recall stumbling across a comment where the word "beint32_t" appeared where "belong" would have made sense in context..

NelsonMinar• 2 years ago

Oh this makes me feel old. When I first learned C declaring functions was very much an optional feature. A good idea, but optional.

WalterBright9• 2 years ago

In the C compiler I wrote a couple years ago (ImportC), since it was re-using the D semantic routines, forward referencing functions "just works".

In fact, it works so well you don't even notice it working. If the C committee wants to improve C, they should make this an official feature.

P.S. Because of the lack of forward referencing, C code tends to be organized as leaves first, and the entry point at the end. This is simply backwards, the entry point should be at the beginning.

cpeterso3• 2 years ago

Are there any compilers our language that parse source files in reverse order? Then you could have a one-pass compiler without forward declarations (though you would need “backward” declarations). :)

Someone shared with me their idea for a parallelized parser, where threads would parse different segments of the source file and then stitch their incomplete ASTs together.

uecker4• 2 years ago

Why surprisingly? In pre-ANSI C is it only possible because there was no type safety. In other languages it could work by deriving the type from the call, but this does not work in C.

dataflow4• 2 years ago

Well it depends on the calling convention. They're right in the sense that this can't be done for arbitrary calling conventions.

Scubabear68• 2 years ago

I really am shocked that GCC took K&R, pre-ANSI C for this long. For Pete’s sake, I was ANSI-fying Aztec C libraries in the late 1980’s!

layer8• 2 years ago

GCC never cared about Pete.

kevin_thibedeau2• 2 years ago

K&R still exists in lots of the GNU userland apps that see little to no updates.

lanstin• 2 years ago

Maybe because they got bundled into distros soon and as a critical dependency. For a long time as the internet ramped, portability meant you could pretty quickly edit a few header files or Makefile to make it compile for your particular hardware/OS. But then as the perl build scripts showed and autoconf tried to spread, it became expected to download and compile with no changes. In the context of a distro, maybe that put pressure to provide quick work around to keep old code compiling with minimal changes to the actual source?

flohofwoe4• 2 years ago

Tbf, all of those changes should not be surprising to any C programmer for at least the last two decades or so. I'm actually surprised that GCC was so lenient for so long.

veltas5• 2 years ago

It wouldn't have been surprising to make this the default in the 90's even. The things here are pretty much never done intentionally post-standardisation. And it's easy to force these back to being just warnings to make old builds work if needed.

iforgotpassword• 2 years ago

The only annoying thing really is the second strict aliasing example, requiring the temporary variable. It just seems really inelegant. But it has been a pitfall ever since, since using an explicit cast removes the warning (now error) but still breaks strict aliasing.

I think the most pragmatic solution is to just compile everything with no strict aliasing. You still get errors for accidental incompatible assignments but won't get bitten by the optimizer.

omoikane• 2 years ago

Implicit int becoming errors is going to break certain IOCCC entries, including some more recent entries that might have done it due to size constraints, for example:

https://www.ioccc.org/years.html#2019_burton

https://www.ioccc.org/years.html#2019_duble

veltas5• 2 years ago

You can still compile these by downgrading the errors to warnings. They are just errors-by-default now.

ezekiel68• 2 years ago

Not hostile toward it, but -- if the IOCCC ceased tomorrow, the world would be neither better nor worse off for the loss (in the grand scheme).

lsllc• 2 years ago

I think it best we keep the folks who like to write that sort of C code busy with the IOCCC rather than out coding in the real world!

veltas5• 2 years ago

This is a long-needed, but gratefully accepted improvement to GCC. I've seen in the wild just how many people see a 'warning' and consider it ignorable, even though many warnings in GCC are certain indication of broken code in pretty much anything new written in the last 35 years.

It's important to bear in mind the main change here is to stop wild C programmers from trying to run or release code that's almost certainly broken, because the diagnostic they got wasn't explicit enough. People can still force the old behaviour if they need to.

marmight• 2 years ago

  > The corrected standard C source code might look like this (still disregarding error handling and short writes):
  >
  >  void
  >  write_string (int fd, const char \*s)
  >  {
  >    write (1, s, strlen (s));
  >  }

And disregarding the passed file descriptor! :)

fweimer3• 2 years ago

Hah! Thanks, fixed.

zzo38computer• 2 years ago

I agree with making most these warnings to be errors by default; actually, they are the same warnings that I had previously thought that should be errors by default (the only exception is incompatible-pointer-types, although that makes sense too to be an error, so it is OK anyways). I think this is good

TapamN2• 2 years ago

The reason for that is that C does not offer a generic function pointer type, and standard C disallows casts between function pointer types and object pointer types.

I've wondered why this hasn't been relaxed a bit when void* is used. Say you have these functions (modified from the link)

  int compare (const char *a, const char *b) {
          return strcmp(a, b);
  }
  
  int compare (const void *a1, const void *b1) {
          const char *a = a1;
          const char *b = b1;
          return strcmp (a, b);
  }

And then you have some FP of type int(*compare)(const void *a1, const void *b1) somewhere...

If you have correct pointer const-ness, why isn't the first method the PREFERRED way of doing this? It's shorter, more clear, safer (calling compare directly and not through a FP still gets you proper type checking (you wouldn't call either of these example functions directly, but for others you might)), and IDE suggestions can better explain what the function is. I've thought several times about suggesting to compiler writers/the C committee to bless the first method. Is there some obscure hardware that the first would be incorrectly compiled or something (i.e. the calling convention for void* and foo* is different)?

bubuche87• 2 years ago

I am not sure I understand what you say (despite having read your message several times), but pointers don't have all the same size. Not always, at least. (void* is supposedly big enough to contain any type of pointer, even if I think I remember I read that it's not necessarily true for function pointers).

And if the size of "void" and "char" aren't the same you cannot push two void* on the stack and pop two char*.

But, like I said: maybe I didn't understood what you said.

TapamN2• 2 years ago

I was wondering if pointer size is still a problem. Hopefully this explanation is clearer:

  int compare_char (const char *a, const char *b) {
          return strcmp(a, b);
  }
  
  int compare_void (const void *a1, const void *b1) {
          const char *a = a1;
          const char *b = b1;
          return strcmp (a, b);
  }
  
  int (*call_void)(const void *a1, const void *b1) = &compare_char; //not valid in current C standard

Why can't the standard be changed so that it is valid to set call_void to &compare_char, so we don't need to write the longer compare_void? Are there architectures are still in active use where not all pointers are the same size in plain C (not worrying about C++) that would disallow this?

AFAIK, x86, ARM, MIPS, SPARC, Alpha, and SuperH would all work fine calling compare_char though call_void. There could be some other issues, like near/far on 16-bit x86, but that would be orthogonal to implicit function pointer void* casting, and could still occur if call_void was set to compare_void. Do one of the more obscure embedded CPUs still in use have a varying pointer size?

dzaima5• 2 years ago

C11:

    A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. [48]
    <blah blah pointers to qualified vs unqualified, structs, and unions also have the same representation between themselves>.
    Pointers to other types need not have the same representation or alignment requirements.
    
    [48]: The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions.

The thing I've heard for systems where e.g. an int* and char* aren't equal is where the "int*" is the "primary" pointer type, and a char* has to add back the would-be-leading-bits or something. Though as per the above quote, char* vs void* would be safe? Doesn't help anything other than char* though.

erik_seaberg• 2 years ago

There used to be hardware that supported pointers to individual bits or complete words, rather than the eight-bit bytes we see today.

https://en.wikipedia.org/wiki/Word_addressing

jart• 2 years ago

It's really sad how the C standards committee is pushing this anti-c89 thing because it breaks one of the most important use cases for C which is writing programs that work under both GCC and JavaScript. See https://justine.lol/sectorlisp2/#evaluation and https://justine.lol/sectorlisp2/#polyglots I've yet to see any explanation of what we stand to gain, by disallowing implicit int. The whole thing just comes across as religious in nature.

DaveFlater• 2 years ago

In C++ this is simply legal code. But in C, the bogus warning has now escalated to a bogus error.

   void fun110 (char const * const *a) {}
   char **a;
   fun110(a);

Porting to GCC 14: C language issues

Related Stories