Opened 14 years ago
Closed 14 years ago
#7554 closed bug (fixed)
signal.h contains send_signal
Reported by: | wretched_dutchman | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | System/POSIX | Version: | R1/Development |
Keywords: | signal.h send_signal | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
When trying to compile apache httpd 2.2 I got the following error:
mpm_common.c:953: error: conflicting types for 'send_signal'
This function is declared by mpm_common and also defined in signal.h. When doing some tracing on signal.h I didn't found a single operating system that declares this function in signal.h.
I don't know how and where send_signal is implemented and used, but I think it should be reconsidered to placing it there.
Change History (4)
follow-up: 2 comment:1 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → in-progress |
Version: | R1/alpha2 → R1/Development |
follow-up: 3 comment:2 by , 14 years ago
Replying to bonefish:
The probably bigger problem is that the symbol (together with other Be API symbols) lives in libroot and can freely clash with symbols unaware (e.g. ported POSIX compliant) third-party code defines.
But that is not really our problem alone, and Linux and the BSDs all come with their own set of functions beyond what POSIX suggests. IIRC they usually just export them as weak symbols, and I don't think there is much else to do besides that anyway.
comment:3 by , 14 years ago
Replying to axeld:
But that is not really our problem alone, and Linux and the BSDs all come with their own set of functions beyond what POSIX suggests. IIRC they usually just export them as weak symbols, and I don't think there is much else to do besides that anyway.
Declaring the symbols weak is only one part of the solution and doesn't help alone. The other is to define non-weak versions of the functions in a system-private namespace (e.g. __*) and use those in the implementation. The glibc does that AFAIK. If we don't do that as well, applications may unknowingly override a function and break libroot functions that use it. send_signal()
is a very good example, as it is e.g. used by pthread_kill()
.
This is quite a bit of (rather boring) work.
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
With hrev42116 the send_signal()
prototype is no longer in <signal.h>
.
send_signal()
is a BeOS extension. Indeed it does not belong to<signal.h>
. I'll see, if it can be moved to<OS.h>
without too much pain. The probably bigger problem is that the symbol (together with other Be API symbols) lives in libroot and can freely clash with symbols unaware (e.g. ported POSIX compliant) third-party code defines.