[ub] Justification for < not being a total order on pointers?

Gabriel Dos Reis gdr at axiomatics.org
Mon Aug 26 20:38:46 CEST 2013


Jeffrey Yasskin <jyasskin at google.com> writes:

| On Mon, Aug 26, 2013 at 11:12 AM, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
| > Chandler Carruth <chandlerc at google.com> writes:
| > | The freedom that optimizing compilers very deeply need is that the
| > | ordering be totally unspecified.
| >
| > Is that enough for what people want when they wish for operator< to be a
| > total order?
| 
| Certainly some people want to guarantee:
| 
| void foo() {
|   int a;
|   int b;
|   assert(&a < &b);
| }
| 
| but they're wrong. ;)

I know, but wait till you get there :-)
People already have that assurance for non-static members. 

| When I suggest that < should be a total order on
| pointers, I don't mean any more than what we've already specified for
| std::less<T*>. The ordering should be unspecified beyond being a total
| order.
| 
| > | So long as we keep this, I have no knowledge of significant negative
| > | impacts on optimizing compilers. If you have other specific
| > | optimizations, please bring them up (clearly, I'm not familiar with
| > | all optimizing compilers! ;])
| >
| > See above.    Note also that I've been careful making a distinction
| > between "optimization" and "program transformation" -- the former appear
| > to be loaded (usually with emotions both ways), while the latter
| > describes a wide range of things compilers and static analysis tools do.
| 
| I think "program transformation" isn't precise enough. Certainly there
| are many transformations that could rely on any piece of unspecified
| behavior, but as long as they're only transformations, I have no
| problem banning them. If they're also optimizations or debugging aids
| or serve some other purpose, then we actually have to decide on a
| trade-off.

"program transformation" in the sense of mapping set of defined behavior
into set defined behaviour.  People rarely rail against the debugger
when it catches them doing something that is undefined; they are more
likely to rail against "optimizer" when the optimizer optimizes
the "wrong code".  Now imagine, the optimizer is optimizing for
safety/security as opposed to code size of number of cycles it takes 
to execute a certain function with certain inputs.  That is why I said
"optimization" tends to be associated with more emotion and expectations.


-- Gaby


More information about the ub mailing list