You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
int main()
{
errno=34; // this will result in the following call throwing an exception
boost::asio::io_context ctx(std::thread::hardware_concurrency());
}
The offending code is in "asio/impl/config.hpp". Calls to strtoull and strtoll are followed by a check for errno==ERANGE, but there is not check first that ensures that the errno is actually relevant and has been set by that call.
Due to ambiguity of whether a return of LONG_MIN/LLONG_MIN/LONG_MAX/LLONG_MAX is due to that value being parsed or due to under/overflow, it seems like the safest course is to set errno=0 before those calls. I have tested this and confirmed that it does avoid the issue.
The text was updated successfully, but these errors were encountered:
We hit the same issue - together with #1587
Please find proposed patch in #1587
Clearing of errno is suggested by POSIX.1-2024 / The Open Group Base Specifications:
strtoul, strtoull — convert a string to an unsigned long
...
These functions shall not change the setting of errno if successful.
Since 0, {ULONG_MAX}, and {ULLONG_MAX} are returned on error and are also valid returns on success, an application wishing to check for error situations should set errno to 0, then call strtoul() or strtoull(), then check errno.
Boost 1.87.0: Construction of io_context throws std::out_of_range if errno=34 before call:
#include
#include <boost/asio/io_context.hpp>
#include
int main()
{
errno=34; // this will result in the following call throwing an exception
boost::asio::io_context ctx(std::thread::hardware_concurrency());
}
The offending code is in "asio/impl/config.hpp". Calls to strtoull and strtoll are followed by a check for errno==ERANGE, but there is not check first that ensures that the errno is actually relevant and has been set by that call.
Due to ambiguity of whether a return of LONG_MIN/LLONG_MIN/LONG_MAX/LLONG_MAX is due to that value being parsed or due to under/overflow, it seems like the safest course is to set errno=0 before those calls. I have tested this and confirmed that it does avoid the issue.
The text was updated successfully, but these errors were encountered: