Bug 209877 - #defining lint trashes _Noreturn, violating C11
Summary: #defining lint trashes _Noreturn, violating C11
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Konstantin Belousov
URL:
Keywords: standards
Depends on:
Blocks:
 
Reported: 2016-05-31 00:09 UTC by eggert
Modified: 2018-09-22 09:22 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eggert 2016-05-31 00:09:56 UTC
A user ran into a problem when building bleeding-edge Emacs and I tracked it down to a compatibility issue with FreeBSD's use of the 'lint' macro in C. You can see the original problem report in <http://bugs.gnu.org/23640> (originally about Cygwin, but look for "FreeBSD" later on in the bug report).

FreeBSD doesn't conform to the C standard in this area. To reproduce the conformance bug, compile the following three-line file t.c:

#define lint 1
#include <stdio.h>
_Noreturn int x;

This C program violates a constraint because _Noreturn is allowed only on function declarations. The C compiler is therefore required to issue a diagnostic. However, the shell command 'cc -std=c11 -S t.c' silently ignores the _Noreturn.

The problem is that FreeBSD headers in /usr/include define _Noreturn to be empty if the symbol 'lint' is defined. But 'lint' is in user space, and users programs are allowed to use it for whatever they want. That's what Emacs was doing, and other programs are like Emacs in this respect, so the problem won't go away by my simply modifying GNU Emacs to use some symbol other than 'lint'.

I suppose that one possible fix would be for cdefs.h to define its own symbol _FreeBSD_Noreturn instead of defining _Noreturn, and for other headers to use _FreeBSD_Noreturn rather than _Noreturn.
Comment 1 Yuri Pankov 2018-09-22 07:12:56 UTC
Lint support has since been removed from system headers, so this should be fixed in the upcoming 12.0 release, see base r326123.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2018-09-22 09:22:28 UTC
Assign to committer that resolved