language-c and C11 support

[mitchty]

Originally reported this to c2hs here and was noted that language-c is providing all of the usefulness: haskell/c2hs#159

Noticed on alpine linux 3.3.1 when compiling the ncurses package. Are there plans for language-c and C11 support? I know this pacage looks to just have changed ownership, and the haskell is a bit beyond my current ability at this point or I'd try to add a fix for the _Noreturn case I hit.

The error log:

Configuring ncurses-0.2.15...
Building ncurses-0.2.15...
Preprocessing library ncurses-0.2.15...
c2hs: C header contains errors:

/usr/include/stdlib.h:44: (column 11) [ERROR]  >>> Syntax error !
  The symbol `void' does not fit here.

And that section of stdlib.h:

_Noreturn void abort (void);
int atexit (void (*) (void));
_Noreturn void exit (int);
_Noreturn void _Exit (int);
int at_quick_exit (void (*) (void));
_Noreturn void quick_exit (int);

For now I just patch stdlib.h and remove the _Noreturn's to work around this:
https://github.com/mitchty/alpine-linux-ghc-bootstrap/blob/master/test-7.10/Dockerfile#L19

But I think a more general approach would be to have language-c start to support C11 constructs. I don't think full on generic support is really needed yet or anything from the appendices.

[visq]

So this particular problem would be fixed if language.c supports the _Noreturn function specifier (C11 6.7.4). Extending Lexer and Parser is trivial. However, the only other function specifier so far was inline, and because of this, function specifiers are not treated in an uniform way in Language.C. Supporting a second function specifier in a proper way will thus require some effort.

[visq]

In order to evaluate the changes necessary for proper C11 support, I reran gcc.dg test suite with language.c 0.5.0. The following (not necessarily complete) list of features needs to be implemented:

• _Noreturn (implemented in HEAD, generalizing function specifiers)
• _Alignas (alignment specifier)
• _Thread_local (new keyword)
• _Atomic (new qualifier)
• static assertions
• generic types

There are a couple of unsupported GNU extensions as well (e.g. auto types), but first aiming at C11 compatibility seems like a good idea. If an unsupported GNU extension is used in system headers, it should be prioritized as well.

[magnusjonsson]

I too would love to see C11 support, especially _Generic.

[evincarofautumn]

I just encountered this issue with _Nonnull and _Nullable in the OS X 10.12 headers.

EDIT: It looks like these are extensions, not C11 features.

[arrowd]

Yes, _Nonnull is a Clang extension. It would be nice to support it, as FreeBSD headers also contain these decls.

[hasufell]

This issue still exists: vmchale/libarchive#12

Especially _Alignas.

[expipiplus1]

I'd be very happy to merge any patch improving C11 support. I do believe that other specifiers such as nonnull are working though, so maybe alignas would be an easy fix (I was under the misapprehension that it worked already in fact!).

…

On Wed, 25 Aug 2021, 2:58 am Julian Ospald, ***@***.***> wrote: This issue still exists: vmchale/libarchive#12 <vmchale/libarchive#12> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXBNK2FONNHYUXGSXRTT6PTWZANCNFSM4B5JNPSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .