Re: Modern C failures in Haskell stack

[Florian Weimer]

* Richard W. M. Jones:

>  We noticed that some ghc-* packages FTBFS with Modern C failures eg
>  these two picked at random:
>
>    https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>    https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
>
>  I think what's happening here is that ghc is generating C FFI code
>  which is fed to GCC 14.  The code being generated is buggy.
>
>  So probably the fix for this is just in ghc itself.  I looked at
>  upstream ghc and wasn't able to identify any commits which fix this
>  (except maybe
>  https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
>  But I didn't look especially hard and the code is very complicated.
>
>  An alternative to fixing this in the compiler is to throw up our hands
>  and add:
>
>    %global build_type_safety_c 0
>
>  to every affected ghc-* package. 
Please don't do this, it's unnecessary busy-work.

>  eg This fixes ghc-readline:
>
>    https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
>
>  Any thoughts on this? 
If GHC cannot be fixed properly, it should be trivial to teach it to
emit #pragma directives near the start of the generated files.  This is
what we currently do for Vala:

<https://src.fedoraproject.org/rpms/vala/blob/rawhide/f/vala-c99.patch>

(The upstream submission has a Clang variant as well.)

Hopefully, GHC has a better understanding of the types and the control
flow of the code it generates than the Vala compiler, so this shouldn't
be necessary.

For the first issue, please try this GHC patch (only compile-tested with
the stage 0 compiler build this point):

diff --git a/compiler/GHC/HsToCore/Foreign/C.hs b/compiler/GHC/HsToCore/Foreign/C.hs
index 2164ded112..8beaa8986e 100644
--- a/compiler/GHC/HsToCore/Foreign/C.hs
+++ b/compiler/GHC/HsToCore/Foreign/C.hs
@@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty is_IO_res_ty
cc
      ,   ppUnless res_hty_is_unit $
          if libffi
                   then char '*' <> parens (ffi_cResType <> char
'*') <>
-                       text "resp = cret;"
+                       text "resp = " <> parens ffi_cResType <>
text "cret;"
                   else text "return cret;"
      , rbrace
      ]

I'm not even sure if there is a better fix for this.  Perhaps emitting a
memcpy call to avoid the aliasing violation?

For the second build failure, GCC reports *genuine* bugs in the C code
in that package, leading to run-time crashes:

cbits/hslibxml-shim.c:44:21: error:
     warning: incompatible implicit declaration of built-in function ‘calloc’
[-Wbuiltin-declaration-mismatch]
       44 |         user_data = calloc(1, sizeof(UserData));
          |                     ^~~~~~

That hasn't been valid C since 1986 or thereabouts.

As Jakub said, you really need to include the appropriate header files
to make this work.

Thanks,
Florian