critical bugs in charconv
Hello Matt,
Sorry for submitting a bug report this way. (Having problems with my GitHub account at the moment).
Code: Attachment (gcc 13.2 -std=gnu++23 -O3 -Wall -fanalyzer)
Errors (normal)
- Missing sign
- Hex exponent is wrong
- Hex is completely wrong
- Accuracy is not correct
- Error code deviates from the standard
...
The backup functions via (quadmath)snprintf do not work.
Errors (critical)
- If the buffer is too small (e.g. set the array size to 3) there are a lot of buffer overflows. Especially with value ±nan/±inf.
The functions should therefore always be structured in the same way:
Auxiliary function
inline constexpr bool is_valid_range(const char*const first, const char*const last) noexcept
{
return (first!=nullptr && last!=nullptr) ? first < last : false;
}
Pseudocode
to_chars(...) // FP
{
to_chars_result
result{last, std::errc::value_too_large};
if (is_valid_range(first, last)) [[likely]]
{
const size_t
size = size_t(last - first);
if (inf or nan) [[unlikely]]
{
if (size is large enough)
{
copy the string values into the range
result = ...;
Here you could also use #define to specify whether the string values are compatible with the standard or not.
"±inf", "±nan"
or https://develop.charconv.cpp.al/#to_chars_usage_notes_for_to_chars_for_float...
}
}
else
{
convert, detail::implemantation(first, size, ...)
result = ...;
}
}
return result;
}
to_chars(...) // INT
{
to_chars_result
result{last, std::errc::value_too_large};
if (is_valid_range(first, last)) [[likely]]
{
const size_t
size = size_t(last - first);
convert, detail::implemantation(first, size, ...)
result = ...;
}
return result;
}
This can be achieved with templates and typetraits:
FP
boost::is_floating_point still does not contain any C++23 types.
template <typename Type>
BOOST_NOINLINE typename std::enable_if
Hello Matt, Sorry for submitting a bug report this way. (Having problems with my GitHub account at the moment).
Code: Attachment (gcc 13.2 -std=gnu++23 -O3 -Wall -fanalyzer)
Errors (normal) - Missing sign - Hex exponent is wrong - Hex is completely wrong - Accuracy is not correct - Error code deviates from the standard ... The backup functions via (quadmath)snprintf do not work.
Errors (critical) - If the buffer is too small (e.g. set the array size to 3) there are a lot of buffer overflows. Especially with value ±nan/±inf.
Gero, I will open issues based on what I can confirm from your test set. It looks like John is handling the type_traits additions. Matt
I will open issues based on what I can confirm from your test set. It looks like John is handling the type_traits additions.
It would be nice if something would actually happen. The bug trackers are full, but (with a few exceptions) *nothing* happens. My point of view: boost has done a lot for C++11, or rather, this is what made C++11 possible in the first place. But you've been stuck with it ever since. Newer C++ versions are not even taken into account or use very old (highly buggy) code for C++03 because no updates have been made. This applies to almost all libraries. boost has thus developed from a progressive to a conservative library. Very often it also happens that requests are shot down immediately. According to the motto "Nobody has needed this before, so you don't need it either!". regards Gero
On 2/5/24 00:25, g.peterhoff--- via Boost wrote:
I will open issues based on what I can confirm from your test set. It looks like John is handling the type_traits additions.
It would be nice if something would actually happen. The bug trackers are full, but (with a few exceptions) *nothing* happens.
My point of view: boost has done a lot for C++11, or rather, this is what made C++11 possible in the first place.
But you've been stuck with it ever since. Newer C++ versions are not even taken into account or use very old (highly buggy) code for C++03 because no updates have been made. This applies to almost all libraries.
boost has thus developed from a progressive to a conservative library.
Very often it also happens that requests are shot down immediately. According to the motto "Nobody has needed this before, so you don't need it either!".
So what's your point?
It would be nice if something would actually happen. The bug trackers are full, but (with a few exceptions) nothing happens.
This is objectively false. You open issues on a number of libraries that John and I maintain and we either address them in a few days, or provide you with valid reasoning that we are not going to action them for one reason or another. I expect the experience is generally the same from the other maintainers on this list. Matt
participants (4)
-
Andrey Semashev
-
g.peterhoff@t-online.de
-
John Maddock
-
Matt Borland