------=_Part_370_1236736980.1405982865536
Content-Type: text/plain; charset=UTF-8

Brainstorm..
One of the most interesting things in Rust is the concept of
pointer-lifetimes for its 'borrowed references' (otherwise similar to &
references)

I thought you could at least annotate tags with some sort of reference
smart pointer taking a tag in a type parameter(a static analyser could then
use that..), but would it be feasible to actually retrofit features that
would let you implement the same lifetime checks.

Perhaps a directive to get the scope blocks' nesting level as an int,
(making it available to TMP..) it would probably need more though

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_370_1236736980.1405982865536
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Brainstorm..<div>One of the most interesting things in Rus=
t is the concept of pointer-lifetimes for its 'borrowed references' (otherw=
ise similar to &amp; references)<div><br></div><div>I thought you could at =
least annotate tags with some sort of reference smart pointer taking a tag =
in a type parameter(a static analyser could then use that..), but would it =
be feasible to actually retrofit features that would let you implement the =
same lifetime checks.</div><div><br></div><div>Perhaps a directive to get t=
he scope blocks' nesting level as an int, (making it available to TMP..) it=
 would probably need more though</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_370_1236736980.1405982865536--

.

------=_Part_206_580729073.1406916887922
Content-Type: text/plain; charset=UTF-8

There's not really anything stopping this from being implemented in the C++
Standard.  It would be possible to make a C++ compiler that implemented
standard pointers and references that way.

The issue you'd run into, though, is that even within what is considered
defined behavior, programs are allowed to reinterpret_cast or memcpy
pointers into std::uintptr_t, do whatever arbitrary math on them--programs
could temporarily encrypt uintptr_ts if they so fancy--then
reinterpret_cast the same value back to a pointer and use it.  So long as
the value of the uintptr_t being cast back to pointer type is the same as
the value that came out of the reinterpret_cast to uintptr_t, this is
fully-defined behavior.  It's also fully-defined to use a char * pointer to
access any type, since otherwise memcpy wouldn't be possible.

This essentially means that a C++ implementation either cannot perfectly
track all pointers--and thus some programs can mess up their heap or
whatever--or an implementation must track pointers based entirely upon
their value rather than anything attached to their type.

A conceivable C++ "sandbox" implementation would be to make all pointers
really large, say 128 bits, then use half the pointer as a handle and half
as an offset.  (Or alternatively, half as a handle and half as the actual
implementation address.)  The handle would be strictly increasing; each
call to operator new, each use of unary & on a stack object and each
binding of a stack object to a reference would allocate a use-once handle
number.  With 2^64 handles, you would be very unlikely to run out in the
runtime lifespan of a given program.  Any time a pointer is dereferenced or
a reference is...dereferenced?, the implementation would verify that the
pointer has not been freed and that the offset is within the bounds of the
allocation.

Melissa

On Monday, July 21, 2014 3:47:45 PM UTC-7, walter1234 wrote:
>
> Brainstorm..
> One of the most interesting things in Rust is the concept of
> pointer-lifetimes for its 'borrowed references' (otherwise similar to &
> references)
>
> I thought you could at least annotate tags with some sort of reference
> smart pointer taking a tag in a type parameter(a static analyser could then
> use that..), but would it be feasible to actually retrofit features that
> would let you implement the same lifetime checks.
>
> Perhaps a directive to get the scope blocks' nesting level as an int,
> (making it available to TMP..) it would probably need more though
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_206_580729073.1406916887922
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There's not really anything stopping this from being imple=
mented in the C++ Standard.&nbsp; It would be possible to make a C++ compil=
er that implemented standard pointers and references that way.<br><br>The i=
ssue you'd run into, though, is that even within what is considered defined=
 behavior, programs are allowed to reinterpret_cast or memcpy pointers into=
 std::uintptr_t, do whatever arbitrary math on them--programs could tempora=
rily encrypt uintptr_ts if they so fancy--then reinterpret_cast the same va=
lue back to a pointer and use it.&nbsp; So long as the value of the uintptr=
_t being cast back to pointer type is the same as the value that came out o=
f the reinterpret_cast to uintptr_t, this is fully-defined behavior.&nbsp; =
It's also fully-defined to use a char * pointer to access any type, since o=
therwise memcpy wouldn't be possible.<br><br>This essentially means that a =
C++ implementation either cannot perfectly track all pointers--and thus som=
e programs can mess up their heap or whatever--or an implementation must tr=
ack pointers based entirely upon their value rather than anything attached =
to their type.<br><br>A conceivable C++ "sandbox" implementation would be t=
o make all pointers really large, say 128 bits, then use half the pointer a=
s a handle and half as an offset.&nbsp; (Or alternatively, half as a handle=
 and half as the actual implementation address.)&nbsp; The handle would be =
strictly increasing; each call to operator new, each use of unary &amp; on =
a stack object and each binding of a stack object to a reference would allo=
cate a use-once handle number.&nbsp; With 2^64 handles, you would be very u=
nlikely to run out in the runtime lifespan of a given program.&nbsp; Any ti=
me a pointer is dereferenced or a reference is...dereferenced?, the impleme=
ntation would verify that the pointer has not been freed and that the offse=
t is within the bounds of the allocation.<br><br>Melissa<br><br>On Monday, =
July 21, 2014 3:47:45 PM UTC-7, walter1234 wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">Brainstorm..<div>One of the most intere=
sting things in Rust is the concept of pointer-lifetimes for its 'borrowed =
references' (otherwise similar to &amp; references)<div><br></div><div>I th=
ought you could at least annotate tags with some sort of reference smart po=
inter taking a tag in a type parameter(a static analyser could then use tha=
t..), but would it be feasible to actually retrofit features that would let=
 you implement the same lifetime checks.</div><div><br></div><div>Perhaps a=
 directive to get the scope blocks' nesting level as an int, (making it ava=
ilable to TMP..) it would probably need more though</div></div></div></bloc=
kquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_206_580729073.1406916887922--

.