[PATCH] Add a prototype for CopyGetMasterEvent()

[Peter Hutterer]

On Wed, Feb 04, 2009 at 12:23:10AM -0200, Paulo César Pereira de Andrade wrote:
> Peter Hutterer wrote:
> > On Wed, Feb 04, 2009 at 12:03:12AM +0100, Tomas Carnecky wrote:
> >> This function is defined in mi/mieq.c and used in xkb/ddxDevBtn.c,
> >> hence it needs a prototype.
> >>
> >> Signed-off-by: Tomas Carnecky <tom at dbservice.com>
> >> ---
> >>  include/input.h |    8 ++++++++
> >>  1 files changed, 8 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/input.h b/include/input.h
> >> index 3b7a173..a91e7e9 100644
> >> --- a/include/input.h
> >> +++ b/include/input.h
> >> @@ -474,6 +474,14 @@ extern _X_EXPORT int AllocMasterDevice(ClientPtr
> >> client,
> >>  extern _X_EXPORT void DeepCopyDeviceClasses(DeviceIntPtr from,
> >>                                    DeviceIntPtr to);
> >>
> >> +extern _X_EXPORT void CopyGetMasterEvent(
> >> +    DeviceIntPtr mdev,
> >> +    DeviceIntPtr sdev,
> >> +    xEvent* original,
> >> +    EventListPtr master,
> >> +    int count
> >> +);
> >> +
> >
> > _X_INTERNAL is the better approach here. CGME should not be visible to
> > anyone
> > but the server itself.
> 
>   IMO _X_INTERNAL should be used with extreme care, as it may cause
> erroneous behavior if not properly used, while _X_HIDDEN always does
> what one would expect, but feel free to tell me otherwise :-) (probably
> a _X_PROTECTED would be more appropriate); _X_INTERNAL is also just
> __hidden attribute for Sun CC. The problem is that a function with
> attribute internal cannot be called via a function pointer by another
> shared object.

oh. my fault then. I assumed _X_INTERNAL was "internal to the server".

>   Also note that in the current way sdksyms.sh parses cpp output,
> it will take the address of that function, because the header is
> in the build tree, and the line starts with extern (currently one
> could cheat by just adding a space before "extern"). So, the proper
> solution should be to declare the symbol in a non sdk header, where
> it would not be required to use any _X_FOO attribute.
> 
>   I plan to convert the "cpp output parser" to generate a linker
> script, what should be significantly more reliable, but the first
> approach was to automatically generate what was once a series of
> hand written and outdated files (but referencing enough symbols to
> prevent the linker from finding "unreachable" symbols, that would
> only be "reachable" from external modules).

it may be good to clean up the header files first.

I know I mostly added functions where I thought they were appropriate, and
looking back now there's a lot of _X_EXPORT's that shouldn't be there.
The kernel uses a #ifdef __KERNEL__ to hide what's internal only from the
header file. Maybe we should be looking at a similar solution. quite frankly,
the EXPORT, HIDDEN, INTERNAL, etc. is confusing me.

Cheers,
  Peter