> -----Original Message-----
> From: Wojtek Lerch [mailto:Wojtek@xxxxxx]
> Sent: Friday, July 03, 2009 6:10 PM
> > The only important things are that
> > pointers to objects have the same size as pointers to functions and
> > that NULL pointers are mapped to NULL pointers.
>
> Don't you mean *at least* the same size? [...]
Yes. (But this wasn't text that was supposed to go in the standard.)
> I don't think it's that simple. POSIX it making the result of certain
> undefined conversions defined, by introducing a new category
> of pointer
> values. There's no such thing as "as usual", because the C
> standard was
> not originally meant to describe the behaviour of those new
> values; its
> wording may rely on the assumption that such values do not
> exist, and it
> may break in surprising ways if they do.
It could. However, C semantics match machine semantics pretty
closely---in fact, machines are being designed to match C semantics---
so I think it's unlikely, or could be fixed with a
tweak or two.
I am looking for a mimimal set of changes. And bascially,
I think the purpose of this review process is to identify
those changes. I personally can't invest the time for a major
revision of the C standard or of POSIX, but given the nature
of the problem, I don't think that is necessary.
[stuff deleted -- your objections are all correct, but
peripheral]
> > So POSIX would have to specify that the analogous
> > conversion would need to be done for function pointers,
> > if it wanted to allow arbitrary comparisons of (uncasted)
> > void pointers with function pointers.
>
> No, I wasn't talking about comparing a pointer to function with a
> pointer to void. That's a constraint violation in standard C, and I
> would prefer POSIX to keep it that way.
Hence my point about compiler warnings.
> I was talking about comparing two pointers to void, if one or both
> pointers are converted function pointers:
>
> void *ptr1 = (void*) malloc, *ptr2 = (void*) free, *ptr3 = (void*)
> free;
> if ( ptr1 == "hi" ) ... // Defined? Guaranteed to be false?
> if ( ptr1 == ptr2 ) ... // Defined? Guaranteed to be false?
> if ( ptr2 == ptr3 ) ... // Defined? Guaranteed to be true?
None of these examples are relevant to the task at hand, namely for
dlsym()
to be able to return pointers to functions and for the null pointer to
be
detected reliably. So POSIX doesn't have to define this.
> > Perhaps it
> > would suffice to say that the result of converting a function
> > designator to a void pointer results in an invalid object pointer,
> > similarly, the result of converting the address of an object to a
> > function pointer results in an invalid function pointer.
>
> I don't like the idea of calling it an "invalid" pointer --
> that sounds
> too much like how the C standard sometimes refers to an "indeterminate
> value".
"Invalid pointer" is a term from the C standard.
To sum up my changes, I would add that:
A pointer to void may be converted to or from a pointer to
function
type. A pointer to function type may be converted to a pointer
to void
and back again; the result shall compare equal to the original
pointer.
The result of converting a function designator to a void pointer
results
in an invalid object pointer; similarly, the result of
converting the address
of an object to pointer to a function results in an invalid
function pointer.
One could, for completeness, also specify that intptr_t and uintptr_t
are wide enough
to hold function pointers, but that is not required by dlsym().
|