native_handle for basic_filebuf

[vadim.pet...@gmail.com]

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

[Billy O'Neal]

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/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com

--
 
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Ville Voutilainen]

On 15 October 2013 02:12, Billy O'Neal <billy...@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".

[Billy O'Neal]

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/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com