Bug 93082 - macOS Authorization.h needs fixinclude
Summary: macOS Authorization.h needs fixinclude
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 9.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-27 12:38 UTC by mcccs
Modified: 2020-11-27 23:27 UTC (History)
4 users (show)

See Also:
Host:
Target: x86_64-darwin
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-12-27 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mcccs 2019-12-27 12:38:57 UTC
This bug has existed for at least two years.

In Authorization.h:

```
static const size_t kAuthorizationExternalFormLength = 32;

typedef struct {
    char bytes[kAuthorizationExternalFormLength];
} AuthorizationExternalForm;
```

GCC prints this error:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7:
error: variably modified 'bytes' at file scope

(from gcc/c/c-decl.c Line 5792)

Clang (-Wall -Wextra): *Compiles without warning*

Clang (-Wall -Wextra -pedantic): warning: variable length array folded to constant array as an extension [-Wgnu-folding-constant]

----

Impact: Golang's official compiler allows linking between C and Go. When I try to build a Go package that imports "crypto/x509" (usually indirectly), part of Go standard library on macOS, and `export CC=gcc-9` is set, Go returns the following error:

# crypto/x509
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:42,
                 from /usr/local/Cellar/go/1.13.5/libexec/src/crypto/x509/root_cgo_darwin.go:17:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: error: variably modified 'bytes' at file scope
  193 |  char bytes[kAuthorizationExternalFormLength];
      |       ^~~~~

Other than a fixinclude, there are other ways:

- Every time after an upgrade, open Authorization.h with sudo vim and replace kAuthorizationExternalFormLength with 32
- Remove `export CC=gcc-9`
- Disable C-Go interlink (on by default)

A fixincludes entry would be quite clean:

fix = {
    hackname  = darwin_authorization;
    mach      = "*-*-darwin*";
    files     = Frameworks/Security.framework/Headers/Authorization.h;
    select    =
    "char bytes[kAuthorizationExternalFormLength];\n";
    c_fix     = format;
    c_fix_arg =
    "char bytes[32];\n";
    test_text =
    "char bytes[kAuthorizationExternalFormLength];\n";
};

However, I can't test it due to PR90835.
Comment 1 Andrew Pinski 2019-12-27 12:44:09 UTC
Why not change:
static const size_t kAuthorizationExternalFormLength = 32;

Into an enum:
enum {
  kAuthorizationExternalFormLength = 32
};

---- CUT ---
-Wgnu-folding-constant
Funny how clang thinks this was an GNU extension when it is not one.
Comment 2 mcccs 2019-12-30 06:32:13 UTC
Reported on the "other side" https://bugs.llvm.org/show_bug.cgi?id=44406

Changing it to enum works too, my only doubt is that it has a different width and sign (but better than not compiling)

Updated patch, thank you Andrew:

fix = {
    hackname  = darwin_authorization;
    mach      = "*-*-darwin*";
    files     = Frameworks/Security.framework/Headers/Authorization.h;
    select    =
    "static const size_t kAuthorizationExternalFormLength = 32;\n";
    c_fix     = format;
    c_fix_arg =
    "enum { kAuthorizationExternalFormLength = 32 };\n";
    test_text =
    "static const size_t kAuthorizationExternalFormLength = 32;\n";
};
Comment 3 Fabian Groffen 2020-11-24 18:28:55 UTC
The problem with this snippet is that it doesn't work on Frameworks, does it?  At least for me, it seems it searches from usr/include only?
Comment 4 mcccs 2020-11-27 21:36:19 UTC
(In reply to Fabian Groffen from comment #3)
> The problem with this snippet is that it doesn't work on Frameworks, does
> it?  At least for me, it seems it searches from usr/include only?

I'm not sure but it sounds likely. Isn't usr/include the higher-priority #include <...> search directory?
Comment 5 Sam James 2020-11-27 23:18:45 UTC
I've also reported this to Apple as FB8919799 (and on openradar - why not? https://openradar.appspot.com/radar?id=4952611266494464).