Project

General

Profile

Feature #9812

headers should be free of SUS compiler tyranny

Added by Robert Mustacchi over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
lib - userland libraries
Start date:
2018-09-09
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Each version of a SUS standard is written with the expectation that the user is using a corresponding release of the ISO C standard. For example, SUSv4 expects ISO C99. Others exception C89. Some may expect C11 or a future revision of the ISO C standard. For an application to be compliant there is a laundry list of things that it needs to be. Notably, it is up to the application to ensure that this is true. These include things like: not using undefined or implementation-defined behavior, not using utilities not part of the standard, etc.

If we think about this in the context of building this means something rather important: the only defined tool that they provide is the compiler driver! This means that there is no ld, there is no gcc, no clang, etc. You have to use c99 (in SUSv4) or a similarly named tool in other versions. When using those tools, the ISO C standard will be set directly by the compiler driver. This means that the application has the ability to control that it is getting the right standard because it is using the only compiler driver which by definition, always does.

As such, I believe we should remove the current check in sys/feature_tests.h and make this the user's responsibility. There are several reasons for this:

1. This is one of the more common pitfalls when building third-party software. No one else enforces it and while it's true that setting -D_XOPEN_SOURCE or -D_POSIX_SOURCE does request the symbol environment for a specific POSIX/SUS revision, it does not do any of the work to enforce the rest of it. The system doesn't try and say wait, you're using gcc and not c99 or that you're passing non-standard cflags, etc. It only controls visible symbols. It can't be understated how often this problem is hit and worked around everywhere.

2. Modern compilers are changing the default C standard that they're building with, which means more and more software dealing with modern compilers like recent releases of gcc and clang change the default away from -std=gnu89. However, because all this software wants the symbol visibility, this is a problem as it will now fail with the newer compiler, even though there's no real good reason to. Almost certainly none of this software is actually a posix application because it's going to use autotools and pass a -W flag.

3. Software that is currently strictly conforming will not become less strictly conforming as a result of this. It is true that it does make it harder to create a strictly conforming application, but I believe that the headers are responsible for a small portion of what makes an application POSIX compliant. Nothing about this suggests that the header's role in changing symbol visibility rules should change.

4. There's nothing in the standard that I can find that explicitly directs us to generate a #error when this occurs.

#1

Updated by Electric Monk over 2 years ago

  • Status changed from New to Closed

git commit be4355ddcfa407e2d3e4a06973af5cbef6ccdbae

commit  be4355ddcfa407e2d3e4a06973af5cbef6ccdbae
Author: Robert Mustacchi <rm@joyent.com>
Date:   2018-09-13T20:50:00.000Z

    9812 headers should be free of SUS compiler tyranny
    Reviewed by: John Levon <john.levon@joyent.com>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Peter Tribble <peter.tribble@gmail.com>
    Reviewed by: Igor Kozhukhov <igor@dilos.org>
    Reviewed by: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
    Reviewed by: Garrett D'Amore <garrett@damore.org>
    Approved by: Garrett D'Amore <garrett@damore.org>

Also available in: Atom PDF