Disabling malloc_usable_size for -D_FORTIFY_SOURCE=3 compatibility
Please provide the following information
libtorrent version (or branch): RC_2_0
platform/architecture: Linux
compiler and compiler version: gcc 12
Arch Linux is preparing switching to -D_FORTIFY_SOURCE=3, upon inspection if all packages I noticed libtorrent uses a function called malloc_usable_size. This function is "for diagnostic purposes only" and should not be used in release builds, as it's going to be considered a fatal memory violation with -D_FORTIFY_SOURCE=3 (source).
Fortunately there's only one place in which libtorrent is using malloc_usable_size, so it would be trivial to patch downstream:
diff --git a/include/libtorrent/aux_/buffer.hpp b/include/libtorrent/aux_/buffer.hpp
index 7d8fe0da2..ce6cf21d4 100644
--- a/include/libtorrent/aux_/buffer.hpp
+++ b/include/libtorrent/aux_/buffer.hpp
@@ -87,17 +87,7 @@ public:
m_begin = static_cast<char*>(std::malloc(static_cast<std::size_t>(size)));
if (m_begin == nullptr) aux::throw_ex<std::bad_alloc>();
- // the actual allocation may be larger than we requested. If so, let the
- // user take advantage of every single byte
-#if (defined __GLIBC__ && !defined __UCLIBC__) || defined __FreeBSD__
- m_size = static_cast<difference_type>(::malloc_usable_size(m_begin));
-#elif defined _MSC_VER
- m_size = static_cast<difference_type>(::_msize(m_begin));
-#elif defined __APPLE__
- m_size = static_cast<difference_type>(::malloc_size(m_begin));
-#else
m_size = size;
-#endif
}
// allocate an uninitialized buffer of the specified size
right, this is an attempted optimization, to make use of as much of the allocation as possible before having to realloc. It can easily be circumvented. You say it's for diagnostic purposes only, is that referring to the glibc function?
Yes, from the glibc malloc_usable_size documentation:
The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of alignment and minimum size constraints. Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation.
The main use of this function is for debugging and introspection.