Opened 8 years ago

Closed 8 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:
Has a Patch: no 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)

comment:1 by bonefish, 8 years ago

Owner: changed from nobody to bonefish
Status: newin-progress
Version: R1/alpha2R1/Development

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.

in reply to:  1 ; comment:2 by axeld, 8 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.

in reply to:  2 comment:3 by bonefish, 8 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 bonefish, 8 years ago

Resolution: fixed
Status: in-progressclosed

With hrev42116 the send_signal() prototype is no longer in <signal.h>.

Note: See TracTickets for help on using tickets.