Infinite recursion in RationalNumberType::isExplicitlyConvertibleTo when comparing m_value == 0

[yuucyf]

Description

When debugging the Solidity compiler source code, I encountered an infinite recursion issue that causes a stack overflow.

Inside the function:

BoolResult RationalNumberType::isExplicitlyConvertibleTo(Type const& _convertTo) const
{
	if (isImplicitlyConvertibleTo(_convertTo))
		return true;

	auto category = _convertTo.category();
	if (category == Category::FixedBytes)
		return false;
	else if (auto addressType = dynamic_cast<AddressType const*>(&_convertTo))
		return (m_value == 0) ||
			((addressType->stateMutability() != StateMutability::Payable) &&
			!isNegative() &&
			!isFractional() &&
			integerType() &&
			(integerType()->numBits() <= 160));
	else if (category == Category::Integer)
		return false;
	else if (auto enumType = dynamic_cast<EnumType const*>(&_convertTo))
		if (isNegative() || isFractional() || m_value >= enumType->numberOfMembers())
			return false;

	Type const* mobType = mobileType();
	return (mobType && mobType->isExplicitlyConvertibleTo(_convertTo));
}

the statement:

return (m_value == 0);

leads to infinite recursion.
This happens because it matches the global overloaded operator:

template <class Arg, class IntType>
BOOST_CONSTEXPR
inline typename boost::enable_if_c<
    rational_detail::is_compatible_integer<Arg, IntType>::value,
    bool
>::type
operator==(const Arg& b, const rational<IntType>& a)
{
    return a == b;
}

I am using Boost 1.74.0.

solidity test code

function _transfer(address from, address to, uint256 value) internal {
    if (from == address(0)) {
        revert ERC20InvalidSender(address(0));
    }
    if (to == address(0)) {
        revert ERC20InvalidReceiver(address(0));
    }
    _update(from, to, value);
}

Expected behavior

The comparison m_value == 0 should evaluate correctly without triggering infinite recursion.

Actual behavior

The comparison triggers the global operator overload, which calls a == b again, leading to infinite recursion and eventually a stack overflow.

Environment

• Compiler version: 0.8.30
• Compilation pipeline:
• Target EVM version (as per compiler settings):
• Framework/IDE (e.g. Foundry, Hardhat, Remix):
• Operating system: Ubuntu 22.04.1 LTS, GCC 11.4.0, Boost 1.74.0

Steps to Reproduce

[yuucyf]

It can be resolved by changing it to m_value.numerator() == 0.
Similarly,

bool isZero() const { return m_value == 0; }

must be modified to:

bool isZero() const { return m_value.numerator() == 0; }

[yuucyf]

When encountering m_value == 0:
Since m_value is of type boost::rational<bigint>, and 0 is an int,
therefore: m_value == 0 is equivalent to: rational<bigint> == int
Because rational defines an operator==, the code is as follows:

template <class T>
BOOST_CONSTEXPR typename boost::enable_if_c<
    rational_detail::is_compatible_integer<T, IntType>::value, bool>::type operator== (const T& i) const
{
    return ((den == IntType(1)) && (num == i));
}

Here, IntType = bigint, T = int.
Therefore, check the condition:

rational_detail::is_compatible_integer<int, bigint>::value

Check the code for is_compatible_integer in Boost, as shown below:

struct is_compatible_integer<FromInt, ToInt, typename enable_if_c<!is_array<FromInt>::value>::type>
   {
      BOOST_STATIC_CONSTANT(bool, value = ((std::numeric_limits<FromInt>::is_specialized && std::numeric_limits<FromInt>::is_integer
         && (std::numeric_limits<FromInt>::digits <= std::numeric_limits<ToInt>::digits)
         && (std::numeric_limits<FromInt>::radix == std::numeric_limits<ToInt>::radix)
         && ((std::numeric_limits<FromInt>::is_signed == false) || (std::numeric_limits<ToInt>::is_signed == true))
         && is_convertible<FromInt, ToInt>::value)
         || is_same<FromInt, ToInt>::value)
         || (is_class<ToInt>::value && is_class<FromInt>::value && is_convertible<FromInt, ToInt>::value));
   };

so:
FromInt = int
ToInt = boost::multiprecision::cpp_int
is_convertible<int, cpp_int>::value returns false, because the constructor of cpp_int is explicit.
is_same<FromInt, ToInt>::value) returns false,
and similarly, (is_class<ToInt>::value && is_class<FromInt>::value && is_convertible<FromInt, ToInt>::value) also returns false.
Therefore, the member operator== function is eliminated by SFINAE(Substitution failure is not an error), and the compiler(GCC v11.x) treats it as non-existent.
Consequently, the compiler proceeds to attempt matching the global operator== version, which is equivalent to operator==(m_value, 0).

The code for the global operator== shown below:

template <class Arg, class IntType>
BOOST_CONSTEXPR
inline typename boost::enable_if_c<
    rational_detail::is_compatible_integer<Arg, IntType>::value,
    bool
>::type
operator==(const Arg& b, const rational<IntType>& a)
{
    return a == b;
}

• Left side: m_value → type rational → binds to const Arg& b. Therefore, Arg = rational.
• Right side: 0 → type int → implicitly convertible to rational, so binds to const rational& a.
  Final deduction result:
  Arg = rational<bigint>
IntType = int

Check the condition:

rational_detail::is_compatible_integer<rational<bigint>, int>::value

This indicates that it ultimately deduces to true, so it calls the global operator== version. However, the global operator== version adjusts the parameter order, leading to continuous recursion.

Just for reference, I’m not sure if my analysis is correct.

Note: Could it also be related to the versions of the Boost(v1.74.0) library and the GCC(11.4)?