When using /dev/random or /dev/urandom on GNU/Linux we can get the bits of available entropy using the RNDGETENTCNT ioctl.
Created attachment 40951 [details] patch Is this OK? Or maybe we should keep the ABI unchanged and put all the implementation in the header random.h?
(In reply to Xi Ruoyao from comment #1) > Or maybe we should keep the ABI unchanged and put all the implementation > in the header random.h? No. It would then pollute the global namespace with sys/ioctl.h and linux/random.h. Worse than an ABI minor ("acceptable" in libstdc++ ABI doc) change.
Right, it's better to add it to the DSO as your first patch does. This will have to wait for gcc8 though. In the meantime I'll email you separately about completing a copyright assignment for GCC.
Author: redi Date: Tue May 23 16:11:57 2017 New Revision: 248374 URL: https://gcc.gnu.org/viewcvs?rev=248374&root=gcc&view=rev Log: PR libstdc++/67578 Implement non-trivial std::random_device::entropy 2017-05-23 Xi Ruoyao <ryxi@stu.xidian.edu.cn> Jonathan Wakely <jwakely@redhat.com> PR libstdc++/67578 * acinclude.m4: Bump libtool_VERSION. * config/abi/pre/gnu.ver: Create GLIBCXX_3.4.24 with new symbol. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Add test for <linux/random.h>. * doc/xml/manual/abi.xml: Document new library version. * include/bits/random.h (random_device::entropy) [_GLIBCXX_USE_RANDOM_TR1]: Add call to new _M_getentropy member. (random_device::_M_getentropy): Declare. * src/c++11/random.cc (random_device::_M_getentropy): Define. * testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.24 to known versions, and make it the latest version. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/xml/manual/abi.xml trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/src/c++11/random.cc trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
Implemented for GCC 8.
N.B. we still return zero for the default random_device if using the RDRAND instruction. I don't know what we could do there, except maybe trust Intel and return the maximum value.