------=_Part_343_33166150.1403842252380
Content-Type: text/plain; charset=UTF-8

Is there a reason that there has not yet been an (std::)(u)intfuncptr_t
defined for C/C++ yet?  The idea makes sense to me.

I think Windows's GetProcAddress and POSIX's dlsym should return it.

Melissa

--

---
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_343_33166150.1403842252380
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Is there a reason that there has not yet been an (std::)(u)intfuncptr_t defined for C/C++ yet?&nbsp; The idea makes sense to me.<br><br>I think Windows's GetProcAddress and POSIX's dlsym should return it.<br><br>Melissa<br></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_343_33166150.1403842252380--

.

Em qui 26 jun 2014, =C3=A0s 21:10:52, Myriachan escreveu:
> Is there a reason that there has not yet been an (std::)(u)intfuncptr_t
> defined for C/C++ yet?  The idea makes sense to me.
>=20
> I think Windows's GetProcAddress and POSIX's dlsym should return it.

Not all platforms have integers the size of function pointers.

The original ABI proposals for IA-64 had=20
 sizeof(void (*)()) =3D=3D 2*sizeof(void*) =3D 16

So we'd need a 128-bit integer for that platform.

A little humour:
$ gcc -xc - <<<'long long long x;'
<stdin>:1:11: error: =E2=80=98long long long=E2=80=99 is too long for GCC

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--Apple-Mail=_56E0F9ED-5462-451D-8DAB-A3C8110A4CB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-27, at 2:41 PM, Thiago Macieira <thiago@macieira.org> wrote:

> Em qui 26 jun 2014, =E0s 21:10:52, Myriachan escreveu:
>> Is there a reason that there has not yet been an (std::)(u)intfuncptr_t
>> defined for C/C++ yet?  The idea makes sense to me.
>>=20
>> I think Windows's GetProcAddress and POSIX's dlsym should return it.
>=20
> Not all platforms have integers the size of function pointers.

That's not actually a problem: the size would simply not be defined.

Currently, we only have uintptr_t, which is capable of holding any void* va=
lue, but function pointers are not convertible to void*. (Signed intptr_t i=
s generally a bad idea; it does exactly the same thing as uintptr_t but it'=
s supposed to be undefined on platforms that might discriminate against int=
eger overflow. Most platforms, in practice, don't, but it's just asking for=
 trouble with a sanitizer.)

(Strangely, =A75.2.10/6 says that reinterpret_cast mediates between functio=
n pointer types, and says "Note: see also 4.10 for more details of pointer =
conversions," where =A74.10 describes void* conversions, but there are no d=
etails there that apply to function pointers.)

The proposal sounds relevant, but since these types are defined by the C st=
andard library, the C++ committee is likely to delegate the decision to the=
m. (Getting POSIX to follow is another story.)

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_56E0F9ED-5462-451D-8DAB-A3C8110A4CB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;27, at 2:41 PM, Thiago Macieira &lt;<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">Em qui 26 jun 2014, =E0s 21:1=
0:52, Myriachan escreveu:<br><blockquote type=3D"cite">Is there a reason th=
at there has not yet been an (std::)(u)intfuncptr_t<br>defined for C/C++ ye=
t? &nbsp;The idea makes sense to me.<br><br>I think Windows's GetProcAddres=
s and POSIX's dlsym should return it.<br></blockquote><br>Not all platforms=
 have integers the size of function pointers.<br></blockquote><div><br></di=
v><div>That&rsquo;s not actually a problem: the size would simply not be de=
fined.</div><div><br></div><div>Currently, we only have <font face=3D"Couri=
er">uintptr_t</font>, which is capable of holding any <font face=3D"Courier=
">void*</font> value, but function pointers are not convertible to <font fa=
ce=3D"Courier">void*</font>. (Signed <font face=3D"Courier">intptr_t</font>=
&nbsp;is generally a bad idea; it does exactly the same thing as <font face=
=3D"Courier">uintptr_t</font>&nbsp;but it&rsquo;s supposed to be undefined =
on platforms that might discriminate against integer overflow. Most platfor=
ms, in practice, don&rsquo;t, but it&rsquo;s just asking for trouble with a=
 sanitizer.)</div><div><br></div><div>(Strangely, =A75.2.10/6 says that <fo=
nt face=3D"Courier">reinterpret_cast</font> mediates between function point=
er types, and says &ldquo;Note:&nbsp;see also&nbsp;4.10&nbsp;for more detai=
ls of pointer conversions,&rdquo; where =A74.10 describes <font face=3D"Cou=
rier">void*</font> conversions, but there are no details there that apply t=
o function pointers.)</div><div><br></div><div>The proposal sounds relevant=
, but since these types are defined by the C standard library, the C++ comm=
ittee is likely to delegate the decision to them. (Getting POSIX to follow =
is another story.)</div><div><br></div></div></body></html>

<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 />

--Apple-Mail=_56E0F9ED-5462-451D-8DAB-A3C8110A4CB0--

.

On 2014-06-27, at 6:05 PM, David Krauss <potswa@gmail.com> wrote:

> That's not actually a problem: the size would simply not be defined.

* the type would not be defined.

--

---
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_1422_28454020.1403930139098
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Friday, June 27, 2014 3:05:48 AM UTC-7, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9327, at 2:41 PM, Thiago Macieira <thi...@maciei=
ra.org=20
> <javascript:>> wrote:
>
> Em qui 26 jun 2014, =C3=A0s 21:10:52, Myriachan escreveu:
>
> Is there a reason that there has not yet been an (std::)(u)intfuncptr_t
> defined for C/C++ yet?  The idea makes sense to me.
>
> I think Windows's GetProcAddress and POSIX's dlsym should return it.
>
>
> Not all platforms have integers the size of function pointers.
>
>
> That=E2=80=99s not actually a problem: the type would simply not be defin=
ed.
>

Even less than a problem is that GCC has an __int128 type on 64-bit=20
targets.  In C++, though not in C, you could even define an INT128_C()=20
macro.  (I don't have an Itanium to test this, though.  I know it works on=
=20
x86-64.)
=20

> Currently, we only have uintptr_t, which is capable of holding any void*=
=20
> value, but function pointers are not convertible to void*. (Signed=20
> intptr_t is generally a bad idea; it does exactly the same thing as=20
> uintptr_t but it=E2=80=99s supposed to be undefined on platforms that mig=
ht=20
> discriminate against integer overflow. Most platforms, in practice, don=
=E2=80=99t,=20
> but it=E2=80=99s just asking for trouble with a sanitizer.)
>

All environments that compile with GCC by default "discriminate against=20
integer overflow" for signed integer types.  Only when you use the -fwrapv=
=20
compiler option do you get signed integer types that properly wrap modulo 1=
=20
<< whatever.  G++'s std::numeric_limits<signed T>::is_modulo is improperly=
=20
set to true, but good luck getting someone to change that.  (I don't know=
=20
how you'd define is_modulo based upon a compiler option when the=20
one-definition-rule could cause multiple object files to conflict.) =20
There's a GCC bug filed about is_modulo since like 2012 but nobody's acted=
=20
upon it other than some discussion.

I don't know what Clang's status is, because I've never gotten it to work=
=20
on any system other than a Mac, and I don't have a Mac.

In Visual C++, other than one extreme edge case I found two days ago, I've=
=20
never seen it consider signed integer overflow undefined or make improper=
=20
assumptions.  The edge case I found might just be a compiler bug.

(Strangely, =C2=A75.2.10/6 says that reinterpret_cast mediates between func=
tion=20
> pointer types, and says =E2=80=9CNote: see also 4.10 for more details of =
pointer=20
> conversions,=E2=80=9D where =C2=A74.10 describes void* conversions, but t=
here are no=20
> details there that apply to function pointers.)
>
> The proposal sounds relevant, but since these types are defined by the C=
=20
> standard library, the C++ committee is likely to delegate the decision to=
=20
> them. (Getting POSIX to follow is another story.)
>
=20
Maybe I should just bring it up with them - though I'm sure that they've=20
heard the idea before.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

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

<div dir=3D"ltr">On Friday, June 27, 2014 3:05:48 AM UTC-7, David Krauss wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:br=
eak-word"><br><div><div>On 2014=E2=80=9306=E2=80=9327, at 2:41 PM, Thiago M=
acieira &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"7KXhvMSeIQ4J" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">thi...@macieira.org</a>&gt=
; wrote:</div><blockquote type=3D"cite">Em qui 26 jun 2014, =C3=A0s 21:10:5=
2, Myriachan escreveu:<br><blockquote type=3D"cite">Is there a reason that =
there has not yet been an (std::)(u)intfuncptr_t<br>defined for C/C++ yet? =
&nbsp;The idea makes sense to me.<br><br>I think Windows's GetProcAddress a=
nd POSIX's dlsym should return it.<br></blockquote><br>Not all platforms ha=
ve integers the size of function pointers.<br></blockquote><div><br></div><=
div>That=E2=80=99s not actually a problem: the type would simply not be def=
ined.</div></div></div></blockquote><div><br>Even less than a problem is th=
at GCC has an __int128 type on 64-bit targets.&nbsp; In C++, though not in =
C, you could even define an INT128_C() macro.&nbsp; (I don't have an Itaniu=
m to test this, though.&nbsp; I know it works on x86-64.)<br>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-wo=
rd"><div><div>Currently, we only have <font face=3D"Courier">uintptr_t</fon=
t>, which is capable of holding any <font face=3D"Courier">void*</font> val=
ue, but function pointers are not convertible to <font face=3D"Courier">voi=
d*</font>. (Signed <font face=3D"Courier">intptr_t</font>&nbsp;is generally=
 a bad idea; it does exactly the same thing as <font face=3D"Courier">uintp=
tr_t</font>&nbsp;but it=E2=80=99s supposed to be undefined on platforms tha=
t might discriminate against integer overflow. Most platforms, in practice,=
 don=E2=80=99t, but it=E2=80=99s just asking for trouble with a sanitizer.)=
</div></div></div></blockquote><div><br>All environments that compile with =
GCC by default "discriminate against integer overflow" for signed integer t=
ypes.&nbsp; Only when you use the -fwrapv compiler option do you get signed=
 integer types that properly wrap modulo 1 &lt;&lt; whatever.&nbsp; G++'s s=
td::numeric_limits&lt;signed T&gt;::is_modulo is improperly set to true, bu=
t good luck getting someone to change that.&nbsp; (I don't know how you'd d=
efine is_modulo based upon a compiler option when the one-definition-rule c=
ould cause multiple object files to conflict.)&nbsp; There's a GCC bug file=
d about is_modulo since like 2012 but nobody's acted upon it other than som=
e discussion.<br><br>I don't know what Clang's status is, because I've neve=
r gotten it to work on any system other than a Mac, and I don't have a Mac.=
<br><br>In Visual C++, other than one extreme edge case I found two days ag=
o, I've never seen it consider signed integer overflow undefined or make im=
proper assumptions.&nbsp; The edge case I found might just be a compiler bu=
g.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word"><div><div>(Strangely, =C2=A75.2.10/6 says that <font =
face=3D"Courier">reinterpret_cast</font> mediates between function pointer =
types, and says =E2=80=9CNote:&nbsp;see also&nbsp;4.10&nbsp;for more detail=
s of pointer conversions,=E2=80=9D where =C2=A74.10 describes <font face=3D=
"Courier">void*</font> conversions, but there are no details there that app=
ly to function pointers.)</div><div><br></div><div>The proposal sounds rele=
vant, but since these types are defined by the C standard library, the C++ =
committee is likely to delegate the decision to them. (Getting POSIX to fol=
low is another story.)</div></div></div></blockquote><div>&nbsp;<br>Maybe I=
 should just bring it up with them - though I'm sure that they've heard the=
 idea before.<br><br></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_1422_28454020.1403930139098--

.

--Apple-Mail=_D8902903-1B0C-42D9-B10B-9C6545B4A751
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-28, at 12:35 PM, Myriachan <myriachan@gmail.com> wrote:

> All environments that compile with GCC by default "discriminate against i=
nteger overflow" for signed integer types.=20

My wording there wasn't very precise, sorry. The minimum requirement is onl=
y that you can go from a pointer to a signed intptr_t and back, which most =
machines will do. Maybe I'm unnecessarily cautious, but representing a poin=
ter as a negative number just sounds wrong to me, and I wouldn't blame a sa=
nitizer for flagging it as an error, regardless of support.

> The proposal sounds relevant, but since these types are defined by the C =
standard library, the C++ committee is likely to delegate the decision to t=
hem. (Getting POSIX to follow is another story.)
> =20
> Maybe I should just bring it up with them - though I'm sure that they've =
heard the idea before.

As for POSIX, quite possible they haven't. The POSIX standard has its own b=
ug tracker, including much debate and commentary leading to each resolution=
, so you should be able to tell exactly if, how, and when.

For C, note that conversion of function pointers to integers is implementat=
ion-defined, regardless of whether a sufficiently large integer type exists=
.. It might be a fly in the ointment.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_D8902903-1B0C-42D9-B10B-9C6545B4A751
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;28, at 12:35 PM, Myriachan &lt;<a href=3D"mailto:myriachan@g=
mail.com">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interc=
hange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>All environm=
ents that compile with GCC by default "discriminate against integer overflo=
w" for signed integer types.&nbsp; </div></div></blockquote><div><br></div>=
<div>My wording there wasn&rsquo;t very precise, sorry. The minimum require=
ment is only that you can go from a pointer to a signed <font face=3D"Couri=
er">intptr_t</font> and back, which most machines will do. Maybe I&rsquo;m =
unnecessarily cautious, but representing a pointer as a negative number jus=
t sounds wrong to me, and I wouldn&rsquo;t blame a sanitizer for flagging i=
t as an error, regardless of support.</div><div><br></div><blockquote type=
=3D"cite"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex; position: static; z-=
index: auto;"><div style=3D"word-wrap:break-word"><div>The proposal sounds =
relevant, but since these types are defined by the C standard library, the =
C++ committee is likely to delegate the decision to them. (Getting POSIX to=
 follow is another story.)</div></div></blockquote><div>&nbsp;<br>Maybe I s=
hould just bring it up with them - though I'm sure that they've heard the i=
dea before.<br></div></div></blockquote><div><br></div></div>As for POSIX, =
quite possible they haven&rsquo;t. The POSIX standard has its own bug track=
er, including much debate and commentary leading to each resolution, so you=
 should be able to tell exactly if, how, and when.<br><div><br></div><div>F=
or C, note that conversion of function pointers to integers is implementati=
on-defined, regardless of whether a sufficiently large integer type exists.=
 It might be a fly in the ointment.</div><div><br></div></body></html>

<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 />

--Apple-Mail=_D8902903-1B0C-42D9-B10B-9C6545B4A751--

.

Em sex 27 jun 2014, =E0s 21:35:38, Myriachan escreveu:
> Even less than a problem is that GCC has an __int128 type on 64-bit=20
> targets.  In C++, though not in C, you could even define an INT128_C()=20
> macro.  (I don't have an Itanium to test this, though.  I know it works o=
n=20
> x86-64.)

Without support from the underlying architecture, such a 128-bit type may b=
e=20
very slow to operate on. In that sense, x86-64 would be faster than IA-64 d=
ue=20
to having a carry flag.

As for IA-64, note I said the initial ABI. It got changed before it went in=
to=20
production because having function pointers be twice as wide as regular=20
pointers was a headache. Instead of pointing to the first bundle of the=20
function, a function pointer points to a pair of 64-bit pointers somewhere =
in=20
memory, one of which is function entry point.

Therefore, I don't know of any actual ABI that makes use of this possibilit=
y=20
given by the standard. The last one was 16-bit DOS when using medium or=20
compact memory models.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

Em s=E1b 28 jun 2014, =E0s 23:25:35, David Krauss escreveu:
> My wording there wasn't very precise, sorry. The minimum requirement is o=
nly
> that you can go from a pointer to a signed intptr_t and back, which most
> machines will do. Maybe I'm unnecessarily cautious, but representing a
> pointer as a negative number just sounds wrong to me, and I wouldn't blam=
e
> a sanitizer for flagging it as an error, regardless of support.

Just a note of experience. We hadn't had the need to store a pointer in a=
=20
signed integer in Qt until 5.0.

The reason we added qintptr is because we needed a cross-platform API that=
=20
could return both a POSIX file descriptor and a Windows HANDLE. The error=
=20
checking is left to the user, which includes comparing for -1.

Arguably, we should have just #ifdef'ed the definition.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--Apple-Mail=_A9B90234-16B2-4F7A-A71F-253D9924396D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-29, at 4:50 AM, Thiago Macieira <thiago@macieira.org> wrote:

> The reason we added qintptr is because we needed a cross-platform API tha=
t=20
> could return both a POSIX file descriptor and a Windows HANDLE. The error=
=20
> checking is left to the user, which includes comparing for -1.
>=20
> Arguably, we should have just #ifdef'ed the definition.

Or just let negative numbers convert to unsigned; that won't break the comp=
arison.

(Although technically, going void* =3D> intptr_t =3D> uintptr_t =3D> void* =
is not well-defined.)

> Without support from the underlying architecture, such a 128-bit type may=
 be=20
> very slow to operate on. In that sense, x86-64 would be faster than IA-64=
 due=20
> to having a carry flag.

And the fact that both use 64-bit function pointers, so 128-bit values neve=
r occur anyway.

> As for IA-64, note I said the initial ABI. It got changed before it went =
into=20
> production because having function pointers be twice as wide as regular=
=20
> pointers was a headache. Instead of pointing to the first bundle of the=
=20
> function, a function pointer points to a pair of 64-bit pointers somewher=
e in=20
> memory, one of which is function entry point.

This is quite a tangent. IA-64 is dead, not least because of its absurdity.

I recall that PowerPC, pre-OS X, Mac OS used "TVectors" comprising a code p=
ointer and a global data pointer. They allow relocatable code without posit=
ion-relative addressing. They were sane enough to keep single-word function=
 pointers though. TVectors were only a detail of dynamic library memory lay=
out and linkage. IA-64 probably came to the same solution, after carefully =
refusing to examine the existing practices.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_A9B90234-16B2-4F7A-A71F-253D9924396D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;29, at 4:50 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">The reason we added qintptr i=
s because we needed a cross-platform API that <br>could return both a POSIX=
 file descriptor and a Windows HANDLE. The error <br>checking is left to th=
e user, which includes comparing for -1.<br></blockquote><blockquote type=
=3D"cite"><br>Arguably, we should have just #ifdef'ed the definition.<br></=
blockquote><div><br></div><div>Or just let negative numbers convert to unsi=
gned; that won&rsquo;t break the comparison.</div></div><br><div>(Although =
technically, going <font face=3D"Courier">void* =3D&gt; intptr_t =3D&gt; ui=
ntptr_t =3D&gt; void*</font> is not well-defined.)</div><div><br></div><div=
></div><blockquote type=3D"cite"><div>Without support from the underlying a=
rchitecture, such a 128-bit type may be&nbsp;<br>very slow to operate on. I=
n that sense, x86-64 would be faster than IA-64 due&nbsp;<br>to having a ca=
rry flag.<br></div></blockquote><div><br></div><div>And the fact that both =
use 64-bit function pointers, so 128-bit values never occur anyway.</div><b=
r><blockquote type=3D"cite"><div>As for IA-64, note I said the initial ABI.=
 It got changed before it went into&nbsp;<br>production because having func=
tion pointers be twice as wide as regular&nbsp;<br>pointers was a headache.=
 Instead of pointing to the first bundle of the&nbsp;<br>function, a functi=
on pointer points to a pair of 64-bit pointers somewhere in&nbsp;<br>memory=
, one of which is function entry point.<br></div></blockquote><div><br></di=
v><div>This is quite a tangent. IA-64 is dead, not least because of its abs=
urdity.</div><div><br></div><div>I recall that PowerPC, pre-OS X, Mac OS us=
ed &ldquo;TVectors&rdquo; comprising a code pointer and a global data point=
er. They allow relocatable code without position-relative addressing. They =
were sane enough to keep single-word function pointers though. TVectors wer=
e only a detail of dynamic library memory layout and linkage. IA-64 probabl=
y came to the same solution, after carefully refusing to examine the existi=
ng practices.</div><div><br></div></body></html>

<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 />

--Apple-Mail=_A9B90234-16B2-4F7A-A71F-253D9924396D--

.

Em dom 29 jun 2014, =E0s 07:27:22, David Krauss escreveu:
> On 2014-06-29, at 4:50 AM, Thiago Macieira <thiago@macieira.org> wrote:
> > The reason we added qintptr is because we needed a cross-platform API t=
hat
> > could return both a POSIX file descriptor and a Windows HANDLE. The err=
or
> > checking is left to the user, which includes comparing for -1.
> >=20
> > Arguably, we should have just #ifdef'ed the definition.
>=20
> Or just let negative numbers convert to unsigned; that won't break the
> comparison.

If we returned a pointer-sized unsigned and someone compared to see if it w=
as=20
smaller than zero, it would generate an always-false situation instead of=
=20
doing the unsigned comparison.

Arguably, the developer should have explicitly compared to -1 instead of le=
ss-
than-zero. Then we could have just warnings of sign conversions.

> > As for IA-64, note I said the initial ABI. It got changed before it wen=
t
> > into production because having function pointers be twice as wide as
> > regular pointers was a headache. Instead of pointing to the first bundl=
e
> > of the function, a function pointer points to a pair of 64-bit pointers
> > somewhere in memory, one of which is function entry point.
>=20
> This is quite a tangent. IA-64 is dead, not least because of its absurdit=
y.

Well, its death has been greatly exaggerated, since Intel's Itanium busines=
s=20
continues to exist and has a revenue greater than its x86 competition...

But the problem I alluded to no longer exists.

> I recall that PowerPC, pre-OS X, Mac OS used "TVectors" comprising a code
> pointer and a global data pointer. They allow relocatable code without
> position-relative addressing. They were sane enough to keep single-word
> function pointers though. TVectors were only a detail of dynamic library
> memory layout and linkage. IA-64 probably came to the same solution, afte=
r
> carefully refusing to examine the existing practices.

That's exactly what it is. The original ABI had the function pointers store=
=20
both the function entry point and the global pointer. The revised ABI point=
s=20
to that pair. Either way, the caller sets up the global pointer for the=20
callee, which allows for intra-library calls to be optimised to not reload =
the=20
pointer.

Another trivia: the virtual table on IA-64 keeps both pointers instead of=
=20
containing the pointer to the "function pointer materialisation".

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

On 2014-06-29, at 7:56 AM, Thiago Macieira <thiago@macieira.org> wrote:

> Arguably, the developer should have explicitly compared to -1 instead of less-
> than-zero. Then we could have just warnings of sign conversions.

Ordered comparison of an unsigned number to a negative one will fairly reliably generate a warning.

> Well, its death has been greatly exaggerated, since Intel's Itanium business
> continues to exist and has a revenue greater than its x86 competition...

Only by a circular definition of "competition" that defines the x86 target market as only existing contracts.

--

---
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/.

.

On 2014-06-29, at 8:02 AM, David Krauss <potswa@gmail.com> wrote:

> the x86 target market as only existing contracts.

* IA-64 target market.


--

---
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/.

.

Em dom 29 jun 2014, =E0s 08:02:05, David Krauss escreveu:
> On 2014-06-29, at 7:56 AM, Thiago Macieira <thiago@macieira.org> wrote:
> > Arguably, the developer should have explicitly compared to -1 instead o=
f
> > less- than-zero. Then we could have just warnings of sign conversions.
>=20
> Ordered comparison of an unsigned number to a negative one will fairly
> reliably generate a warning.

Ordered comparison of an unsigned number to zero will not necessarily gener=
ate=20
a warning, as it's perfectly legal code, no type promotions involved. It mi=
ght=20
produce a diagnostic, since it's an always-true or always-false condition, =
but=20
the warning may be silenced or not be implemented at all.

 if (socket->socketDescriptor() < 0)
  socket->setSocketDescriptor(some_fd);

Also note another requirement: this function returned int in Qt 4, so the c=
ode=20
above could have existed. We didn't want to have silent or near-silent (jus=
t a=20
compiler warning) breakages after the upgrade.

> > Well, its death has been greatly exaggerated, since Intel's Itanium
> > business continues to exist and has a revenue greater than its x86
> > competition...
> Only by a circular definition of "competition" that defines the x86 targe=
t
> market as only existing contracts.

Sorry, that was a convoluted way to say that Intel's Itanium business is=20
larger that AMD's whole business.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

------=_Part_100_3017907.1404017053825
Content-Type: text/plain; charset=UTF-8

In C++ we already have to deal with the prospect of fat function pointers
in the form of member functions on pretty much any compiler but DMC.  I was
also going to mention pre-NeXT Mac OS, but looks like someone beat me to
that. =)

One of my crazier ideas, one I'm sure will be much more controversial, is
to introduce a concept of a "flat address space".  An implementation could
have a #define they can set to indicate that the following are true:

 - alignof(void *), alignof(char *), alignof(uintptr_t), alignof(intptr_t)
are the same.  Not required for sizeof, but due to the next requirement,
but it's highly likely.
 - These types can be reinterpret_cast among one another (or static_cast
for the void */char * and uintptr_t/intptr_t cases) in any order any number
of times and not result in undefined behavior.  CV-qualifiers included, of
course.
 - In addition to among each other, if they originally pointed to some
other data type, pointers to that other type would be included in the list.
 - Addition or subtraction on a uintptr_t or an intptr_t then casting back
to pointer type is equivalent to casting to char *, doing the arithmetic on
the char *, then casting back.  That is, unless such arithmetic results in
overflow or underflow on an intptr_t, which is undefined if the
implementation has std::numeric_limits<intptr_t>::is_modulo == false.
 - Placing void */char */intptr_t/uintptr_t/other_data_pointer into a union
then accessing a different field of the union that is another of these work
equivalently to a reinterpret_cast and therefore not result in undefined
behavior in itself.
 - There is no requirement that intptr_t/uintptr_t have the same range as
ptrdiff_t or size_t.  A flat address space could have its largest possible
object be smaller than its address space.  An architecture I can think of
that's like this is the Super Nintendo.  It has a segmented memory
architecture, but it doesn't have any potential for overlapping like 16-bit
DOS.  You could say that it has a 24-bit flat address space but 16-bit
size_t and ptrdiff_t in one interpretation.  Memory blocks can't cross 64K
boundaries due to the segments, but that's malloc's problem.

Even if an implementation actually *had* a flat address space, it wouldn't
be required to do this.  I'd say the system ought to be true for an
intfuncptr_t.

--

---
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_100_3017907.1404017053825
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In C++ we already have to deal with the prospect of fat fu=
nction pointers in the form of member functions on pretty much any compiler=
 but DMC.&nbsp; I was also going to mention pre-NeXT Mac OS, but looks like=
 someone beat me to that. =3D)<br><br>One of my crazier ideas, one I'm sure=
 will be much more controversial, is to introduce a concept of a "flat addr=
ess space".&nbsp; An implementation could have a #define they can set to in=
dicate that the following are true:<br><br>&nbsp;- alignof(void *), alignof=
(char *), alignof(uintptr_t), alignof(intptr_t) are the same.&nbsp; Not req=
uired for sizeof, but due to the next requirement, but it's highly likely.<=
br>&nbsp;- These types can be reinterpret_cast among one another (or static=
_cast for the void */char * and uintptr_t/intptr_t cases) in any order any =
number of times and not result in undefined behavior.&nbsp; CV-qualifiers i=
ncluded, of course.<br>&nbsp;- In addition to among each other, if they ori=
ginally pointed to some other data type, pointers to that other type would =
be included in the list.<br>&nbsp;- Addition or subtraction on a uintptr_t =
or an intptr_t then casting back to pointer type is equivalent to casting t=
o char *, doing the arithmetic on the char *, then casting back.&nbsp; That=
 is, unless such arithmetic results in overflow or underflow on an intptr_t=
, which is undefined if the implementation has std::numeric_limits&lt;intpt=
r_t&gt;::is_modulo =3D=3D false.<br>&nbsp;- Placing void */char */intptr_t/=
uintptr_t/other_data_pointer into a union then accessing a different field =
of the union that is another of these work equivalently to a reinterpret_ca=
st and therefore not result in undefined behavior in itself.<br>&nbsp;- The=
re is no requirement that intptr_t/uintptr_t have the same range as ptrdiff=
_t or size_t.&nbsp; A flat address space could have its largest possible ob=
ject be smaller than its address space.&nbsp; An architecture I can think o=
f that's like this is the Super Nintendo.&nbsp; It has a segmented memory a=
rchitecture, but it doesn't have any potential for overlapping like 16-bit =
DOS.&nbsp; You could say that it has a 24-bit flat address space but 16-bit=
 size_t and ptrdiff_t in one interpretation.&nbsp; Memory blocks can't cros=
s 64K boundaries due to the segments, but that's malloc's problem.<br><br>E=
ven if an implementation actually *had* a flat address space, it wouldn't b=
e required to do this.&nbsp; I'd say the system ought to be true for an int=
funcptr_t.<br></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_100_3017907.1404017053825--

.