------=_Part_569_20541759.1381792147052
Content-Type: text/plain; charset=ISO-8859-1

Very small and local proposal:

*std::thread, std::mutex, std::condition_variable* have *native_handle_type
native_handle()* method for access to some implementation-defined
underlying system facilities
*
*
*std::basic_filebuf* could have the same method with the same semantics
In practice it would act like fileno(FILE*), but for C++ file buffers

P.S. It seems like various implementations of IO library had similar fd()
method in the past, but it was dropped for some reasons

--

---
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_569_20541759.1381792147052
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Very small and local proposal:</div><div><br></div><d=
iv><em>std::thread, std::mutex, std::condition_variable</em> have <em>nativ=
e_handle_type native_handle()</em> method for access to some implementation=
-defined underlying system facilities</div><div><em><br></em></div><div><em=
>std::basic_filebuf</em> could have the same method with the same semantics=
</div><div>In practice it would act like fileno(FILE*), but for C++ file bu=
ffers</div><div><br></div><div>P.S. It seems like various implementations o=
f IO library had similar fd() method in the past, but it was dropped for so=
me reasons</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_569_20541759.1381792147052--

.

--001a11c309e822719204e8bb9e8f
Content-Type: text/plain; charset=ISO-8859-1

This raises ownership issues. Having a native handle accessor works for the
thread components because once control has left the thread components'
code, the threat components' no longer need complete control over the
object. That isn't true for streams though, which typically do some of
their own buffering. You would need to define some sort of semantics
whereby accessing the native handle would be well defined.

You also would need to mandate that the C++ streams be implemented directly
such that there was a 1:1 native handle relationship, which may not be the
case. For instance, a valid implementation of C++ iostreams would be on top
of cstdio, which would not have any kind of native handle to expose.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Oct 14, 2013 at 4:09 PM, <vadim.petrochenkov@gmail.com> wrote:

> Very small and local proposal:
>
> *std::thread, std::mutex, std::condition_variable* have *native_handle_type
> native_handle()* method for access to some implementation-defined
> underlying system facilities
> *
> *
> *std::basic_filebuf* could have the same method with the same semantics
> In practice it would act like fileno(FILE*), but for C++ file buffers
>
> P.S. It seems like various implementations of IO library had similar fd()
> method in the past, but it was dropped for some reasons
>
> --
>
> ---
> 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/.
>

--

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

--001a11c309e822719204e8bb9e8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This raises ownership issues. Having a native handle acces=
sor works for the thread components because once control has left the threa=
d components&#39; code, the threat components&#39; no longer need complete =
control over the object. That isn&#39;t true for streams though, which typi=
cally do some of their own buffering. You would need to define some sort of=
 semantics whereby accessing the native handle would be well defined.<div>

<br></div><div>You also would need to mandate that the C++ streams be imple=
mented directly such that there was a 1:1 native handle relationship, which=
 may not be the case. For instance, a valid implementation of C++ iostreams=
 would be on top of cstdio, which would not have any kind of native handle =
to expose.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Oct 14, 2013 at 4:09 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:vadim.petrochenkov@gmail.com" target=3D"_=
blank">vadim.petrochenkov@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

<div dir=3D"ltr"><div>Very small and local proposal:</div><div><br></div><d=
iv><em>std::thread, std::mutex, std::condition_variable</em> have <em>nativ=
e_handle_type native_handle()</em> method for access to some implementation=
-defined underlying system facilities</div>

<div><em><br></em></div><div><em>std::basic_filebuf</em> could have the sam=
e method with the same semantics</div><div>In practice it would act like fi=
leno(FILE*), but for C++ file buffers</div><div><br></div><div>P.S. It seem=
s like various implementations of IO library had similar fd() method in the=
 past, but it was dropped for some reasons</div>

</div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c309e822719204e8bb9e8f--

.

--047d7bdc1018e26a2404e8bc7496
Content-Type: text/plain; charset=ISO-8859-1

On 15 October 2013 02:12, Billy O'Neal <billy.oneal@gmail.com> wrote:

> This raises ownership issues. Having a native handle accessor works for
> the thread components because once control has left the thread components'
> code, the threat components' no longer need complete control over the
> object. That isn't true for streams though, which typically do some of
> their own buffering. You would need to define some sort of semantics
> whereby accessing the native handle would be well defined.
>
> You also would need to mandate that the C++ streams be implemented
> directly such that there was a 1:1 native handle relationship, which may
> not be the case. For instance, a valid implementation of C++ iostreams
> would be on top of cstdio, which would not have any kind of native handle
> to expose.
>
>
>
The semantics of fstreams are defined in terms of the underlying cstdio
functions, so there's
no native handle in the picture, and the implementation can indeed not have
such a handle.

Even with such hindrances, I would very much welcome adding native handle
support,
especially for constructing fstreams from open native handles, which would
allow
platform-specific special open operations to be used.

The question we should answer is whether such things need to be
standardized, or whether
things like Boost.Iostreams allow users to do such things well enough. My
quick answers would be
"please, yes" and "close, but not close enough".

--

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

--047d7bdc1018e26a2404e8bc7496
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 15 October 2013 02:12, Billy O&#39;Neal <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.=
com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">This raises ownership issue=
s. Having a native handle accessor works for the thread components because =
once control has left the thread components&#39; code, the threat component=
s&#39; no longer need complete control over the object. That isn&#39;t true=
 for streams though, which typically do some of their own buffering. You wo=
uld need to define some sort of semantics whereby accessing the native hand=
le would be well defined.<div>


<br></div><div>You also would need to mandate that the C++ streams be imple=
mented directly such that there was a 1:1 native handle relationship, which=
 may not be the case. For instance, a valid implementation of C++ iostreams=
 would be on top of cstdio, which would not have any kind of native handle =
to expose.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">

</font></span></div><div class=3D"gmail_extra"><span class=3D"HOEnZb"><font=
 color=3D"#888888"><br><br></font></span></div></blockquote><div><br></div>=
<div>The semantics of fstreams are defined in terms of the underlying cstdi=
o functions, so there&#39;s<br>
no native handle in the picture, and the implementation can indeed not have=
 such a handle.<br><br></div><div>Even with such hindrances, I would very m=
uch welcome adding native handle support,<br>especially for constructing fs=
treams from open native handles, which would allow<br>
</div><div>platform-specific special open operations to be used.<br><br></d=
iv><div>The question we should answer is whether such things need to be sta=
ndardized, or whether<br></div><div>things like Boost.Iostreams allow users=
 to do such things well enough. My quick answers would be<br>
</div><div>&quot;please, yes&quot; and &quot;close, but not close enough&qu=
ot;. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bdc1018e26a2404e8bc7496--

.

--089e0160c35e4c933c04e8be9157
Content-Type: text/plain; charset=ISO-8859-1

They're defined in terms of that, but I don't believe there's any
requirement that they actually be implemented in terms of that.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Oct 14, 2013 at 5:13 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 15 October 2013 02:12, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> This raises ownership issues. Having a native handle accessor works for
>> the thread components because once control has left the thread components'
>> code, the threat components' no longer need complete control over the
>> object. That isn't true for streams though, which typically do some of
>> their own buffering. You would need to define some sort of semantics
>> whereby accessing the native handle would be well defined.
>>
>> You also would need to mandate that the C++ streams be implemented
>> directly such that there was a 1:1 native handle relationship, which may
>> not be the case. For instance, a valid implementation of C++ iostreams
>> would be on top of cstdio, which would not have any kind of native handle
>> to expose.
>>
>>
>>
> The semantics of fstreams are defined in terms of the underlying cstdio
> functions, so there's
> no native handle in the picture, and the implementation can indeed not
> have such a handle.
>
> Even with such hindrances, I would very much welcome adding native handle
> support,
> especially for constructing fstreams from open native handles, which would
> allow
> platform-specific special open operations to be used.
>
> The question we should answer is whether such things need to be
> standardized, or whether
> things like Boost.Iostreams allow users to do such things well enough. My
> quick answers would be
> "please, yes" and "close, but not close enough".
>
>  --
>
> ---
> 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/.
>

--

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

--089e0160c35e4c933c04e8be9157
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">They&#39;re defined in terms of that, but I don&#39;t beli=
eve there&#39;s any requirement that they actually be implemented in terms =
of that.</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D=
"ltr">

<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Oct 14, 2013 at 5:13 PM, Ville V=
outilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.=
com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 15 October 2013 02:12, Billy O&#39;Neal <span =
dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">=
billy.oneal@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">This raises ownership issues. Having a na=
tive handle accessor works for the thread components because once control h=
as left the thread components&#39; code, the threat components&#39; no long=
er need complete control over the object. That isn&#39;t true for streams t=
hough, which typically do some of their own buffering. You would need to de=
fine some sort of semantics whereby accessing the native handle would be we=
ll defined.<div>




<br></div><div>You also would need to mandate that the C++ streams be imple=
mented directly such that there was a 1:1 native handle relationship, which=
 may not be the case. For instance, a valid implementation of C++ iostreams=
 would be on top of cstdio, which would not have any kind of native handle =
to expose.</div>


<span><font color=3D"#888888">

</font></span></div><div class=3D"gmail_extra"><span><font color=3D"#888888=
"><br><br></font></span></div></blockquote><div><br></div></div><div>The se=
mantics of fstreams are defined in terms of the underlying cstdio functions=
, so there&#39;s<br>


no native handle in the picture, and the implementation can indeed not have=
 such a handle.<br><br></div><div>Even with such hindrances, I would very m=
uch welcome adding native handle support,<br>especially for constructing fs=
treams from open native handles, which would allow<br>


</div><div>platform-specific special open operations to be used.<br><br></d=
iv><div>The question we should answer is whether such things need to be sta=
ndardized, or whether<br></div><div>things like Boost.Iostreams allow users=
 to do such things well enough. My quick answers would be<br>


</div><div>&quot;please, yes&quot; and &quot;close, but not close enough&qu=
ot;. <br></div></div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5=
">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0160c35e4c933c04e8be9157--

.