------=_Part_47106_1069134468.1528285572033
Content-Type: multipart/alternative;
 boundary="----=_Part_47107_824776385.1528285572033"

------=_Part_47107_824776385.1528285572033
Content-Type: text/plain; charset="UTF-8"

There is a bug in glibc which seems to have arisen from ambiguity about
distance_type in std::iterator_traits.  It does not have defined required
operators or constructors, but is implied to behave line a signed integer.

https://en.cppreference.com/w/cpp/iterator/iterator_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015

This causes an issue with instrumentation of distance_type as everything
must be implicitly convertible to and from an int.  This is testable by
trying to build the following project:
https://github.com/anadon/Sort-Comparisons-and-Performance-metrics

The code of this original use case was from 1997 by David Musser and so was
permissible when the stdlib was being developed.

I think the following clarifications are in order:
std::iterator_traits::difference_type shall not necessarily be of any
particular built in datatype, but have the following properties:
* All arithmetic operators available to signed integers must be defined
* Implicit constructor from a signed integer type (std::ptrdiff_t) to
itself shall be available
* An implicit conversion to any number type must not be present.

This change, if found reasonable and valid, should be added backwards
through C++11 as a clarification.

--
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/5bceda10-ca60-4100-8fb3-16fcb8713552%40isocpp.org.

------=_Part_47107_824776385.1528285572033
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>There is a bug in glibc which seems to have arisen fr=
om ambiguity about distance_type in std::iterator_traits.=C2=A0 It does not=
 have defined required operators or constructors, but is implied to behave =
line a signed integer.<br></div><div><br></div><div>https://en.cppreference=
..com/w/cpp/iterator/iterator_traits<br></div><div></div><div>https://gcc.gn=
u.org/bugzilla/show_bug.cgi?id=3D86015</div><div><br></div><div>This causes=
 an issue with instrumentation of distance_type as everything must be impli=
citly convertible to and from an int.=C2=A0 This is testable by trying to b=
uild the following project:</div><div>https://github.com/anadon/Sort-Compar=
isons-and-Performance-metrics<br></div><div><br></div><div>The code of this=
 original use case was from 1997 by David Musser and so was permissible whe=
n the stdlib was being developed.</div><div><br></div><div>I think the foll=
owing clarifications are in order:<br></div><div>std::iterator_traits::diff=
erence_type shall not necessarily be of any particular built in datatype, b=
ut have the following properties:</div><div>* All arithmetic operators avai=
lable to signed integers must be defined</div><div>* Implicit constructor f=
rom a signed integer type (std::ptrdiff_t) to itself shall be available</di=
v><div>* An implicit conversion to any number type must not be present.</di=
v><div><br></div><div>This change, if found reasonable and valid, should be=
 added backwards through C++11 as a clarification.<br></div></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/5bceda10-ca60-4100-8fb3-16fcb8713552%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5bceda10-ca60-4100-8fb3-16fcb8713552=
%40isocpp.org</a>.<br />

------=_Part_47107_824776385.1528285572033--

------=_Part_47106_1069134468.1528285572033--

.

------=_Part_47765_2130986432.1528292809923
Content-Type: multipart/alternative;
 boundary="----=_Part_47766_841153955.1528292809923"

------=_Part_47766_841153955.1528292809923
Content-Type: text/plain; charset="UTF-8"

It looks like this will end up needed to be a change in the next standard,
mainly about C++17 27.2.1 [iterator.requirements.general] paragraph 1.

On Wednesday, June 6, 2018 at 7:46:12 AM UTC-4, joshua.r.ma...@gmail.com
wrote:
>
> There is a bug in glibc which seems to have arisen from ambiguity about
> distance_type in std::iterator_traits.  It does not have defined required
> operators or constructors, but is implied to behave line a signed integer.
>
> https://en.cppreference.com/w/cpp/iterator/iterator_traits
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015
>
> This causes an issue with instrumentation of distance_type as everything
> must be implicitly convertible to and from an int.  This is testable by
> trying to build the following project:
> https://github.com/anadon/Sort-Comparisons-and-Performance-metrics
>
> The code of this original use case was from 1997 by David Musser and so
> was permissible when the stdlib was being developed.
>
> I think the following clarifications are in order:
> std::iterator_traits::difference_type shall not necessarily be of any
> particular built in datatype, but have the following properties:
> * All arithmetic operators available to signed integers must be defined
> * Implicit constructor from a signed integer type (std::ptrdiff_t) to
> itself shall be available
> * An implicit conversion to any number type must not be present.
>
> This change, if found reasonable and valid, should be added backwards
> through C++11 as a clarification.
>

--
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/b5426ee6-f221-4342-b346-0963828a1ba9%40isocpp.org.

------=_Part_47766_841153955.1528292809923
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It looks like this will end up needed to be a change =
in the next standard, mainly about C++17 27.2.1 [iterator.requirements.gene=
ral] paragraph 1.</div><div><br></div>On Wednesday, June 6, 2018 at 7:46:12=
 AM UTC-4, joshua.r.ma...@gmail.com wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div>There is a bug in glibc which seems to ha=
ve arisen from ambiguity about distance_type in std::iterator_traits.=C2=A0=
 It does not have defined required operators or constructors, but is implie=
d to behave line a signed integer.<br></div><div><br></div><div><a href=3D"=
https://en.cppreference.com/w/cpp/iterator/iterator_traits" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fiterator%2Fiterator_=
traits\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHKWOFdJjU1PvnpRNG8hkN993R_bQ=
&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fiterator%2Fiterator_trai=
ts\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHKWOFdJjU1PvnpRNG8hkN993R_bQ&#39=
;;return true;">https://en.cppreference.com/w/<wbr>cpp/iterator/iterator_tr=
aits</a><br></div><div></div><div><a href=3D"https://gcc.gnu.org/bugzilla/s=
how_bug.cgi?id=3D86015" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2=
Fbugzilla%2Fshow_bug.cgi%3Fid%3D86015\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGvuk46boEAFTZ-yuAE7jYwNn0hdA&#39;;return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2F=
show_bug.cgi%3Fid%3D86015\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGvuk46boE=
AFTZ-yuAE7jYwNn0hdA&#39;;return true;">https://gcc.gnu.org/bugzilla/<wbr>sh=
ow_bug.cgi?id=3D86015</a></div><div><br></div><div>This causes an issue wit=
h instrumentation of distance_type as everything must be implicitly convert=
ible to and from an int.=C2=A0 This is testable by trying to build the foll=
owing project:</div><div><a href=3D"https://github.com/anadon/Sort-Comparis=
ons-and-Performance-metrics" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.c=
om%2Fanadon%2FSort-Comparisons-and-Performance-metrics\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNGwXzfFetG64BeOL8yIafwFThST5w&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.c=
om%2Fanadon%2FSort-Comparisons-and-Performance-metrics\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNGwXzfFetG64BeOL8yIafwFThST5w&#39;;return true;">https:/=
/github.com/anadon/<wbr>Sort-Comparisons-and-<wbr>Performance-metrics</a><b=
r></div><div><br></div><div>The code of this original use case was from 199=
7 by David Musser and so was permissible when the stdlib was being develope=
d.</div><div><br></div><div>I think the following clarifications are in ord=
er:<br></div><div>std::iterator_traits::<wbr>difference_type shall not nece=
ssarily be of any particular built in datatype, but have the following prop=
erties:</div><div>* All arithmetic operators available to signed integers m=
ust be defined</div><div>* Implicit constructor from a signed integer type =
(std::ptrdiff_t) to itself shall be available</div><div>* An implicit conve=
rsion to any number type must not be present.</div><div><br></div><div>This=
 change, if found reasonable and valid, should be added backwards through C=
++11 as a clarification.<br></div></div></blockquote></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/b5426ee6-f221-4342-b346-0963828a1ba9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5426ee6-f221-4342-b346-0963828a1ba9=
%40isocpp.org</a>.<br />

------=_Part_47766_841153955.1528292809923--

------=_Part_47765_2130986432.1528292809923--

.