--001a114b4444e74c17053a54ca17
Content-Type: text/plain; charset=UTF-8

Given this:
https://www.securecoding.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array

We see the summary that, formally, the only pointer arithmetic operations
that are defined are:

   - taking the difference of 2 pointers *within the same array*
   - comparing using < 2 pointers *within the same object*

....but what I want to do depends on being able to form *well-defined
pointer subtractions* (to *std::ptrdiff_t*) *between bytes within the
object representation in the same object*, or usually just between an
arbitrary byte and the base address, i.e. given

   - *auto const someBytePointer{ reinterpret_cast<unsigned char const
   *>(&someObj.someMember) };*
   - *std::ptrdiff_t myOffset{ someBytePointer - reinterpret_cast<unsigned
   char const *>(&someObj) };*

I want to be able to *guarantee *that myOffset *will *hold the *distance in
unsigned char* between *someObj.someMember* and the base address of
*someObj*

However, I don't think the above guarantees specifically allow this. And
I'm not sure the wording elsewhere that any object can be considered as a '
*sequence*' of *unsigned char* - the object representation - formally
allows said sequence to be considered as an *array* in order to get around
the 1st allowed piece of arithmetic earlier... or that there's any other
allowance making this well-defined.

Anyhow, TL;DR, the questions:

   - *Is *this well-defined? Or am I relying on UB here?
   - *Can *this be made well-defined? *Martin Sebor* at another CERT page -
   https://www.securecoding.cert.org/confluence/display/c/ARR37-C.+Do+not+add+or+subtract+an+integer+to+a+pointer+to+a+non-array+object?focusedCommentId=58359845#comment-58359845
   - (after I believe mistakenly inferring that any object can be treated as
   an *array* of *unsigned char*, rather than the verbatim wording
   *sequence*) - says this:

If the decision is to retain this rule I believe that, at minimum, *an
> exception should be added to make it possible to treat an object as an
> array of unsigned char*, otherwise there's would be no way to implement
> user-defined variants of memset() or memcpy() without violating this
> standard.
>
> But* I do still think this rule is overly restrictive and the decision to
> prohibit treating non-array objects of any type equivalently to arrays of a
> single element should be reconsidered.* To avoid violating the rule,
> programmers whose code is subject to this standard would have to define all
> objects that might be potentially treated as arrays as arrays of size 1.
> That's an infeasible requirement in systems consisting of libraries or
> modules whose public APIs expose individual objects.
>
So there might be some momentum already for specifically defining this. I
hope so! (Otherwise I'll have to radically rethink my design, as this would
be the only piece of formal UB in my current project)

Thanks for any thoughts!

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHSbgPy5AOBHbrF6uepqmsWPBHKZkJ9tKU6Poji0HPMJw%40mail.gmail.com.

--001a114b4444e74c17053a54ca17
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Given this: <a href=3D"https://www.securecoding.cert.=
org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+t=
hat+do+not+refer+to+the+same+array">https://www.securecoding.cert.org/confl=
uence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+no=
t+refer+to+the+same+array</a><br><br></div>We see the summary that, formall=
y, the only pointer arithmetic operations that are defined are:<br><ul><li>=
taking the difference of 2 pointers <b>within the same array</b></li><li>co=
mparing using &lt; 2 pointers <b>within the same object</b></li></ul><p>...=
but what I want to do depends on being able to form <b>well-defined pointer=
 subtractions</b> (to <i>std::ptrdiff_t</i>) <b>between bytes within the ob=
ject representation in the same object</b>, or usually just between an arbi=
trary byte and the base address, i.e. given<br></p><ul><li><i>auto const so=
meBytePointer{ reinterpret_cast&lt;unsigned char const *&gt;(&amp;someObj.s=
omeMember) };</i></li><li><i>std::ptrdiff_t myOffset{ someBytePointer - rei=
nterpret_cast&lt;unsigned char const *&gt;(&amp;someObj) };</i></li></ul><p=
>I want to be able to <b>guarantee </b>that myOffset <b>will </b>hold the <=
b>distance in <i>unsigned char</i></b> between <i>someObj.someMember</i> an=
d the base address of <i>someObj</i></p><p>However, I don&#39;t think the a=
bove guarantees specifically allow this. And I&#39;m not sure the wording e=
lsewhere that any object can be considered as a &#39;<b>sequence</b>&#39; o=
f <i>unsigned char</i> - the object representation - formally allows said s=
equence to be considered as an <b>array</b> in order to get around the 1st =
allowed piece of arithmetic earlier... or that there&#39;s any other allowa=
nce making this well-defined.</p><p>Anyhow, TL;DR, the questions:</p><ul><l=
i><b><i>Is</i> </b>this well-defined? Or am I relying on UB here?</li><li><=
b><i>Can</i> </b>this be made well-defined? <b>Martin Sebor</b> at another =
CERT page - <a href=3D"https://www.securecoding.cert.org/confluence/display=
/c/ARR37-C.+Do+not+add+or+subtract+an+integer+to+a+pointer+to+a+non-array+o=
bject?focusedCommentId=3D58359845#comment-58359845">https://www.securecodin=
g.cert.org/confluence/display/c/ARR37-C.+Do+not+add+or+subtract+an+integer+=
to+a+pointer+to+a+non-array+object?focusedCommentId=3D58359845#comment-5835=
9845</a> - (after I believe mistakenly inferring that any object can be tre=
ated as an <b>array</b> of <i>unsigned char</i>, rather than the verbatim w=
ording <b>sequence</b>) - says this:</li></ul><blockquote style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" c=
lass=3D"gmail_quote"><div class=3D"">
                <p>If the decision is to retain this rule I believe=20
that, at minimum, <b>an exception should be added to make it possible to=20
treat an object as an array of <code>unsigned char</code></b>, otherwise th=
ere&#39;s would be no way to implement user-defined variants of <code>memse=
t()</code> or <code>memcpy()</code> without violating this standard.</p>

<p>But<b> I do still think this rule is overly restrictive and the decision
 to prohibit treating non-array objects of any type equivalently to=20
arrays of a single element should be reconsidered.</b> To avoid violating=
=20
the rule, programmers whose code is subject to this standard would have=20
to define all objects that might be potentially treated as arrays as=20
arrays of size 1. That&#39;s an infeasible requirement in systems consistin=
g
 of libraries or modules whose public APIs expose individual objects.</p>
            </div></blockquote><div>So there might be some momentum already=
 for specifically defining this. I hope so! (Otherwise I&#39;ll have to rad=
ically rethink my design, as this would be the only piece of formal UB in m=
y current project)<br><br></div><div>Thanks for any thoughts!<br><br></div>=
<p><br></p><p><br></p></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHSbgPy5AOBHbrF6uepqmsWPBHKZkJ9=
tKU6Poji0HPMJw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHSbgPy5AOB=
HbrF6uepqmsWPBHKZkJ9tKU6Poji0HPMJw%40mail.gmail.com</a>.<br />

--001a114b4444e74c17053a54ca17--

.