David R Tribble <david.tribble@central.beasys.com> writes:

|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:
|>  > Consider:
|>  >     bool
|>  >     compare( void (*p1)() , void (*p2)() )
|>  >     {
|>  >         return p1 < p2 ;
|>  >     }
|>  >
|>  > Can the compiler optimize it to always return false, since if p1 and p2
|>  > do not point to the same function, the user has invoked unspecified
|>  > results?
|>
|>  What if 'p1' is NULL?  What does the standard say about the relative
|>  ordering of NULL and non-NULL pointers?

Nothing.  In fact, it says that (in the above), if both pointers are
NULL, the results are false, if both pointers point to the same
function, the results are false, and otherwise, the results are
undefined (and thus may also be false).

The same thing holds for data pointers: if both are NULL, > and < return
false, >= and <= return true, but if one is NULL and the other not, the
results are undefined.

|>  Keep in mind that zero is treated
|>  as a null pointer value, but that the actual representation could be
|>  anything (such as 0xFF000000, which is what IBM/370 uses for 24-bit
|>  addressable programs).
|>
|>  And what if, on your system, you really want to find out the relative
|>  addresses of the functions (such as for some sort of embedded debugger)?

On your system, you can check the system documentation, and see what
they actually do in this case.  On at least one of my systems (Sun
Sparc), the implementation actually defines a total ordering over *all*
pointers, so this works.  I think that this is also true on the other
system (HP 700).  (I act as if it were true in my portability modules,
but now that I write this, it occurs that I never checked it for
function pointers, only for data pointers.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christian Bau wrote:
>
> May I add another question to this: Why does comparing unrelated pointers
> result in undefined behavior? (I know there is no reason why in this
> example p1 should be less than p2, but it would not be unreasonable that
> for any two pointers that are not equal, either p1 < p2 or p1 > p2 should
> always be true). For example, given an array int a [100]; and a pointer
> int* p; there seems to be no way to check if the pointer p points to an
> element of a except by comparing it with a, a+1, a+2 etc. etc. instead of
> writing p >= &a [0] && p <= &a [99]

Pointers that do not address memory within single storage allocation
may be incomparable.  An example of this is the architecture of the
AS/400 system which provides no way to manipulate a pointer containing
an address to one object (segment) such that it will address a
different object (segment).  There is no implied order between the
addresses of two different objects, so all relational operators
between such addresses return false.

--
  George Timms
  Work: timms@vnet.ibm.com      Home: gtimms@ibm.net
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Another question: is there any purpose in not forbidding comparison for
inequality on pointers to functions, since the results are only defined
if the pointers point to the same function?

Consider:

    bool
    compare( void (*p1)() , void (*p2)() )
    {
     return p1 < p2 ;
    }

Can the compiler optimize it to always return false, since if p1 and p2
do not point to the same function, the user has invoked unspecified
results?  (A good compiler could certainly generate a warning, although
I suspect that the case occurs so rarely in real code that nobody
bothers.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:
> Consider:
>     bool
>     compare( void (*p1)() , void (*p2)() )
>     {
>         return p1 < p2 ;
>     }
>
> Can the compiler optimize it to always return false, since if p1 and p2
> do not point to the same function, the user has invoked unspecified
> results?

What if 'p1' is NULL?  What does the standard say about the relative
ordering of NULL and non-NULL pointers?  Keep in mind that zero is treated
as a null pointer value, but that the actual representation could be
anything (such as 0xFF000000, which is what IBM/370 uses for 24-bit
addressable programs).

And what if, on your system, you really want to find out the relative
addresses of the functions (such as for some sort of embedded debugger)?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <rf5vi7nqu4g.fsf@vx.cit.alcatel.fr>, James Kanze
<james-albert.kanze@vx.cit.alcatel.fr> wrote:

> Another question: is there any purpose in not forbidding comparison for
> inequality on pointers to functions, since the results are only defined
> if the pointers point to the same function?
>
> Consider:
>
>     bool
>     compare( void (*p1)() , void (*p2)() )
>     {
>         return p1 < p2 ;
>     }
>
> Can the compiler optimize it to always return false, since if p1 and p2
> do not point to the same function, the user has invoked unspecified
> results?  (A good compiler could certainly generate a warning, although
> I suspect that the case occurs so rarely in real code that nobody
> bothers.)

May I add another question to this: Why does comparing unrelated pointers
result in undefined behavior? (I know there is no reason why in this
example p1 should be less than p2, but it would not be unreasonable that
for any two pointers that are not equal, either p1 < p2 or p1 > p2 should
always be true). For example, given an array int a [100]; and a pointer
int* p; there seems to be no way to check if the pointer p points to an
element of a except by comparing it with a, a+1, a+2 etc. etc. instead of
writing p >= &a [0] && p <= &a [99]

And another related question:

Given a declaration

   int a, b, c;

There is a good chance that a, b and c are stored in consecutive memory
locations. So on many compilers you will find that &b = &a + 1 or &b = &c
+ 1. Is it legal if the result of

   &b == &a + 1 || b == &c + 1

is true on a certain compiler?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]