> -----Original Message-----
> From: Schwarz, Konrad [mailto:konrad.schwarz@xxxxxx]
...
> > 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 don't think how that's related to the point I was trying to make...
Perhaps I should clarify it.
In standard C, the following are two equivalent ways of specifying the
same behaviour:
#1 "If the void pointer is a null pointer, then X. Otherwise, Y".
#2 "If the void pointer points to an object or to past the end of an
array, then Y. Otherwise, X".
But you are introducing non-null pointers that don't point to any object
ot past the end of an array. This means that depending on whether C
chose to use wording #1 or #2, the behaviour of your new pointers will
be specified as either X or Y. Should you not care which one it is?
...
> > 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.
But my point is that the C standard already defines the comparisons,
poerhaps not in a way thet POSIX would want it defined. C defines it in
terms of what object or function the pointers point; do you consider the
converted void* pointer to still point to a function, or do you consider
it an "invalid" pointer that doesn't point anywhere until converted back
to a function pointer? The meaning of the text in the C standard that
you want to define the behaviour of those comparisons depends on that
decision.
> > > 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.
Yes, but what does it *mean* in the C standard? Does it not mean an
"indeterminate value"? Indeterminate values can't even be assigned to a
variable or returned from a function.
|