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

Re: Return type of dlsym

To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: Return type of dlsym
From: "Wojtek Lerch" <yyyyyy@xxxxxxx>
Date: Tue, 16 Apr 2002 16:05:42 -0400 (EDT)
Cc: yyyyyyyyyy@xxxxxxxxxx (Seeds Glen)
[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().]

Clive D.W. Feather wrote:
> > Wojtek Lerch said:
> >> The funny thing is that I don't think the result of converting between a
> >> data pointer and a function pointer by va_arg() is defined anywhere --
> >> it seems to me that the text specifically says that the behaviour is not
> >> undefined, but fails to define the behaviour...
> 
> I wrote:
> > Then it's undefined behaviour. Failing to define behaviour is the same as
> > saying "it's undefined".
> 
> Seeds, Glen said:
> > I'm a little uncomfortable with the last statement.
> 
> Sorry, but that's stated *explicitly* in C90 and C99.
> 
> However, in this instance I think I misspoke.
> 
> Wojtek is, I presume, talking about code like this:
> 
>     typedef void (*vif_ptr)(int);
> 
>     void f (int n, ...)
>     {
>         va_list ap;
>         vif_ptr fptr;
> 
>         va_start (ap, n);
>         fptr = va_arg (ap, vif_ptr);
>         va_end (ap);
>         (*fptr)(n);
>     }
> 
>     // ...
> 
>     int x;
>     f (42, &x);
> 
> That is, the argument type is an object pointer but va_arg fetches a
> function pointer (or vice versa).

Yes, but without the line that tries to call *fptr.  Just fetching it
and storing it in a variable was all I had in mind.

> 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:

    If [...], or if type is not compatible with the type of the actual
    next argument (as promoted [...]), the behavior is undefined, except
    for the following cases:

        * One type is a signed integer type, [...]

        * One type is a pointer to void and the other is a pointer to a
        character type.

        * [XSI] Both types are pointers.

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.  That's what I found funny.  In a sad way, of
course.  OK, I guess "funny" wasn't the best possible choice of word.
:-)


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