This can be also be reproduced directly in the ghc-<VERSION>/utils/hp2ps/ source using the Haskell cabal-install build tool (which triggers configure):

$ fedpkg clone ghc9.12  # (or just ghc)
$ cd ghc9.12
$ fedpkg prep
$ cd BUILD/ghc-9.12.1/utils/hp2ps
$ sudo dnf install cabal-install
$ cabal build

(this voids multiple minutes of ghc source building)

I could imagine there are other related failures in the mass rebuild since this seems unrelated to GHC.

Perhaps it is some old code dunno?  Though it has worked for 13 years...

https://gitlab.haskell.org/ghc/ghc/-/blob/master/utils/hp2ps/Utilities.c?ref_type=heads

But there are lots of other type mismatch errors coming up in the mass rebuild unfortunately.

https://kojipkgs.fedoraproject.org/mass-rebuild/f42-failures.html

From my own packages: I think most of

    chez-scheme
    clang13
    eb
    editline
    emacspeak
    ghc-hashtables
    ghc-language-java
    ghc-readline
    ghc-system-fileio

decathorp mentioned that "this looks related to the C23 change wrt/ no arguments vs. undefined arguments vs. void argument"
so moving to gcc

Except this is not a gcc bug.  You should fix ghc or wherever it is to be valid C23 or make sure you build with -std=gnu17 if you want to stay in C17.
See https://gcc.gnu.org/gcc-15/porting_to.html for some details.
Note, declarations like
extern void *realloc();
has been obsolescent already in C99, C11 and C17, so programs had at least 14 years to adapt.

Okay I see: 14 years of ignoring such warnings is certainly a long time... hm

Do you know how many fedora packages are affected roughly?

Perhaps a C23 Fedora Change would have made sense?

David Malcolm should have such data.
In any case, the functions declared with unspecified parameters are a security risk and maintenance burden, all calls to such functions have to get the number and type of their arguments right, the compiler can't diagnose errors about their misuses.
Which is why C89 and C++ introduced declaration of types of the arguments.  C++ has been requiring that since the beginning, C89 just recommending but unspecified ones were accepted for compatibility with K&R.
The C23 change makes void foo (); mean the same thing like in C++, i.e. void foo (void);

I filed https://gitlab.haskell.org/ghc/ghc/-/issues/25662 upstream, but that is just one of many packages.

(In reply to Jakub Jelinek from comment #7)
> Except this is not a gcc bug.  You should fix ghc or wherever it is to be
> valid C23 or make sure you build with -std=gnu17 if you want to stay in C17.
> See https://gcc.gnu.org/gcc-15/porting_to.html for some details.
> Note, declarations like
> extern void *realloc();
> has been obsolescent already in C99, C11 and C17, so programs had at least
> 14 years to adapt.

Might be nice to mention this and how to inject -std=gnu17, etc in the Toolchain Change page?
I guess one can append it to CFLAGS?

Fixed in upstream git by https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13838

This is not portable:

extern void* malloc(long unsigned int);

Declaring your prototypes for functions that need to reference _t types like size_t is not supported by POSIX. You need to include <stdlib.h>.

And not just generally non-portable, but non-portable for some Fedora architectures as well, e.g. i686 has size_t unsigned int rather than unsigned long int, .

Thank you for pointing out my elementary mistake :thanks:

I put up https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13853 to use size_t

(Fortunately or not the previous fix is not built in Fedora yet anyway - since I only tried it for ghc9.0
which failed to link its rts on s390x)

Why don't you just #include <stdlib.h> and drop the declaration altogether?
Even C89 had malloc/realloc/free/calloc etc. declared in stdlib.h, I think even K&R had that.

Okay I see, thanks, now I understand that is even what Florian suggested above...

Does the order of the #include matter particularly?

```
@@ -2,8 +2,7 @@
 #include <stdio.h>
 #include <string.h>
 #include "Error.h"
-
-extern void* malloc();
+#include <stdlib.h>
```
?

The order of standard includes doesn't matter, for others it really matters what they are doing.
Though, as a matter of style, usually system headers are included first, followed by project local headers, at least most of the time (with some exceptions like autoconf generated config.h or similar).

Thanks

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13863

Hopefully the last one.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.