[PATCH] Add a prototype for CopyGetMasterEvent()

Paulo César Pereira de Andrade pcpa at mandriva.com.br
Tue Feb 3 18:23:10 PST 2009

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.

  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).

> Cheers,
>   Peter


More information about the xorg mailing list