C++ Logo

sg12

Advanced search

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

From: Lawrence Crowl <Lawrence_at_[hidden]>
Date: Thu, 17 Oct 2013 15:56:25 -0700
On 10/17/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Nevin Liber <nevin_at_[hidden]> writes:
> > 3. Pointers, while historically not totally ordered, are
> > practically so for all systems in existence today, with the
> > exception of the ivory tower minds of the committee, so the
> > point is moot.
>
> You keep repeating the "history" bits. That is fine. History
> is important, not just because it talks about specific event
> at specific points in the past, but also because it gives us
> perspective over what followed and what is to come.
>
> I personally do not care about the relevance of segmented
> architectures at this specific point in time. However, I am
> very much open to be persuaded of their relevance in the
> future, non-uniform address spaces, etc, but then I would
> likely press and ask whether you should consider different
> kinds of pointers etc.

I have this concern as well, particularly with regard to
capability-based architectures. These have been less than
successful up until now, but security is growing in importance.

I can imagine an architecture in which, for security reasons,
you can tell when two capabilities point to the same segment,
but you cannot order them. Converting the capabilities to
integers would defeat the security, so intptr_t tricks will
probably not work.

However, it has become clear that we need to order pointers
that derive from something other than elements of the same
array.

Suppose, for the sake of discussion, that we say that pointers
to data allocated within the same segment are ordered. The
model is basically exposing the char array of the raw memory.

Of course, we do not have segments in the language right now.
Or, rather, perhaps we have only one data segment comprising
both stack and the one heap. Maybe the problem we should be
considering is how we adapt C++ to unordered address spaces.

-- 
Lawrence Crowl

Received on 2013-10-18 00:56:28