Email List: Xaustin-group-lX
[All Lists]

Re: ACTION 2002-5-5 dlsym() interpretation ( XSH ERN 13)

To: <yyyyyyyyyyyyyy@xxxxxxxxxxxxx>
Subject: Re: ACTION 2002-5-5 dlsym() interpretation ( XSH ERN 13)
From: "Wojtek Lerch" <yyyyyy@xxxxxxx>
Date: Tue, 28 May 2002 01:04:47 -0000
"H. Peter Anvin" <yyy@xxxxxxxxx> said:
> I have to agree that the ERN seems to be incorrect, and that casting via
> void *, although technically nonportable, is in practice a much cleaner
> option.
> 
> The C standards people didn't define a "generic function pointer" -- one
> could, for example, have imagined that "void (*)(...)" should have been
> able to encode any function pointer with the appropriate cast.  If so,

The C Standard guarantees that *any* function pointer is able to encode any 
other function pointer, provided you use the appropriate cast.

> that would have been at least theoretically feasible to use.  Requiring
> such a generic function pointer would be a less invasive extension to
> the C standard than requiring that void * can encode a function pointer
> in a lossless manner.

But the C Standard doesn't guarantee that function pointers can encode a data 
pointer, either.  The problem with dlsym() is that it's used for *both* data 
pointers and functions pointers.
 
> However, in practice I think existing POSIX/Unix practice is to assume,
> widely, that casting a function pointer back and forth to void * is a
> lossless operation.  I believe it is better to encode that requirement
> explicitly as being a case of existing practice.  On modern
> architectures, it's hardly a painful requirement.

At least not on the ones that have a working implementation of dlsym()...

> (It is also widely assumed that memset(...,0,...) is a valid way to
> initialize an array of NULL pointers...)

Yes, but POSIX doesn't justify that assumption, does it?

<Prev in Thread] Current Thread [Next in Thread>