overloaded extern(C) function declarations are allowed

[dlangBugzillaToGithub]

Kenji Hara (@9rnsr) reported this on 2015-10-17T13:39:36Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=15217

CC List

• Walter Bright (@WalterBright)
• Martin Nowak (@MartinNowak)
• Adam Wilson
• Johan Engelen (@JohanEngelen)

Description

Simple test case:

extern (C) void foo(void function() fp);
extern (C) void foo(void function() @nogc fp) @nogc;


This is included in issue 14147, but it's actually used in current druntime code to ignore attribute differences.

----

extern (C):

private alias void function(int) sigfn_t;

nothrow @nogc
{
    private alias void function(int) sigfn_t2;
}

version (CRuntime_Glibc)
{
    sigfn_t bsd_signal(int sig, sigfn_t func);

  nothrow:
  @nogc:
    sigfn_t2 bsd_signal(int sig, sigfn_t2 func);
}

----

The extern (C) bsd_signal function is overloaded but they refers same link symbol '_bsd_signal'.

[dlangBugzillaToGithub]

jbc.engelen (@JohanEngelen) commented on 2016-03-29T17:34:32Z

"GetMonitorInfoA" is also overloaded in this way in druntime,
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/winuser.d#L4425-L4428

[dlangBugzillaToGithub]

code (@MartinNowak) commented on 2018-02-23T12:01:11Z

This was invented as a tool to deprecate callbacks missing those attributes.
There is unfortunately no wildcard to infer function attributes from parameter (callback) attributes, though this use-case comes up frequently (e.g. in interface and class methods besides extern(C) methods).

[dlangBugzillaToGithub]

flyboynw commented on 2018-11-29T11:25:54Z

I still don't understand why this is not treated as an error. It's obviously generating incorrect C ABI's in this case. If it's used to support a specific (or deprecated) path it needs to be deprecated or warning (ugh) so that we can remove the parts that rely on it and get to a conforming state.

[dlangBugzillaToGithub]

bugzilla (@WalterBright) commented on 2018-12-02T02:48:41Z

A possible solution to this conundrum is to allow two C overloads of the same function name if they are defined in the same scope. They'd be disallowed if they were in different scopes. The latter would most likely be accidental. A possibility would be to disallow it unless the declarations are both @system.