Bug 12738 – core.sys.posix.signal sigaction_t handler type mismatch
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
druntime
Product
D
Version
D2
Platform
x86
OS
Linux
Creation time
2014-05-12T16:39:00Z
Last change time
2014-06-19T22:50:50Z
Assigned to
nobody
Creator
hsteoh
Comments
Comment #0 by hsteoh — 2014-05-12T16:39:38Z
Code:
-----
extern(C) void myHandler(int sig) {}
void main() {
import core.sys.posix.signal;
sigaction_t n;
n.sa_handler = &myHandler;
}
-----
Compiler output:
-----
test.d(7): Error: cannot implicitly convert expression (& myHandler) of type extern (C) void function(int sig) to extern (C) void function(int) nothrow
-----
This used to work in 2.065.0.
Comment #1 by hsteoh — 2014-05-12T16:40:48Z
extern(C) functions are nothrow by definition, so this code should not be rejected.
Comment #2 by hsteoh — 2014-05-12T16:52:53Z
This problem is caused by druntime commit 5a04c20ae7863cd320df4c58d801f769acf2d414 (pull request #752).
Comment #3 by bugzilla — 2014-05-12T17:35:24Z
(In reply to hsteoh from comment #1)
> extern(C) functions are nothrow by definition,
This would be a change to the language. Probably a good change, but a change nevertheless, and is likely to break existing code.
Comment #4 by andrej.mitrovich — 2014-05-12T18:44:54Z
(In reply to hsteoh from comment #1)
> extern(C) functions are nothrow by definition
Since when? All extern(C) does is changes the calling convention and mangling. You could easily have a C++ library throw exceptions in an extern(C) function, and the same is true for D.
Comment #5 by r.sagitario — 2014-05-13T06:29:58Z
Is the signal handler allowed to throw? If not, then it is correct that the code does not compile. But I agree that this becomes pretty inconvenient especially when it is changed after being in the wild. The same happened with @nogc: https://issues.dlang.org/show_bug.cgi?id=12710
Should the callbacks be excluded from nothrow?
Comment #6 by r.sagitario — 2014-05-13T06:33:59Z
(In reply to Walter Bright from comment #3)
> (In reply to hsteoh from comment #1)
> > extern(C) functions are nothrow by definition,
>
> This would be a change to the language. Probably a good change, but a change
> nevertheless, and is likely to break existing code.
I also thought that this might be handy, but we would need a way to mark some of them "throw" then, especially in cases where extern(C) is not used to interface with C, but to declare functions without importing the respective module.
Comment #7 by hsteoh — 2014-05-13T17:52:22Z
I'm OK with saying that extern(C) does not guarantee nothrow.
But please keep in mind that this attribute change in the signature of the signal handler BREAKS EXISTING CODE. Possibly in a major way. This is going to cause a lot of user unhappiness if the next release just causes this breakage with no prior warning. Are we sure that's what we want to do?
(My own code can be easily fixed to avoid this problem, but that may not be true in other, more complicated codebases.)