Wojtek Lerch said:
> [This is not really relevant to the subject. The va_arg() requirement
> is not equivalent to requiring that representations of all data pointers
> and function pointers must be identical in the context of dlsym().]
It's not equivalent, no.
[...]
>> If so, then this is *explicitly* undefined behaviour (7.15.1.1#2).
> The thing is that POSIX repeats the last portion of 7.15.1.1#2 but adds
> another case to the end of the "except for" list:
> * [XSI] Both types are pointers.
I missed that.
> To me, the above reads as if the author felt that this was sufficient to
> define the behaviour for all possible combinations of pointer types; but
> I don't think it is.
Actually, it is. More than that, it means that the implementation must
contain enough mechanism to have *a* type which can hold both function
pointer and data pointer values (since it must be able to pass around
values of that type in the stdargs interface). That makes implementing a
single dlsym function somewhat easier.
However, the return type could still need to be different. In other words,
the above [XSI] line requires enough structure that we could say:
* dlsym_t is a pointer type;
* dlsym () returns NULL or a valid dlsym_t value;
* the only thing that can be done with dlsym_t values is to cast them
to the correct pointer type, in which case the right thing happens.
Note that many implementations can set dlsym_t to void *, others can set it
to (void (*)(void)), but a few may have to have another type.
--
Clive D.W. Feather | Work: <yyyyy@xxxxxxxxx> | Tel: +44 20 8371 1138
Internet Expert | Home: <yyyyy@xxxxxxxxxx> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | | NOTE: fax number change
|