[Bug libstdc++/107092] New: std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[Bug libstdc++/107092] New: std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107092

            Bug ID: 107092
           Summary: std::for_each_n and its friends incorrectly accept
                    size parameters that are not convertible to an integer
                    type
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: de34 at live dot cn
  Target Milestone: ---

This program shouldn't compile due to [alg.foreach]/16:

> Mandates: The type Size is convertible to an integral type ([conv.integral], [class.conv]).

It's obvious that BadFrom can't be converted to any integral type.

#include <algorithm>
#include <concepts>

struct BadFrom {
    template<std::same_as<double> D>
    operator D() const
    {
        return 42.0;
    }
};


int main()
{
    int arr[42]{};
    std::for_each_n(arr, BadFrom{}, [](int){});
}

However, this is accepted by libstdc++, because the conversion is done by
__size_to_integer overloads in stl_algobase.h (added via PR 87982), and
overloads for floating-point types are (probably) incorrectly provided.

Godbolt link: https://godbolt.org/z/EKvx7dY4e

While I believe the current "is convertible to an integral type" requirement is
defective (as ambiguity is not considered at all), I think libstdc++ should
reject using BadFrom as Size.

[Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107092

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-09-30
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The reason I added overloads for floating-point types is that they can be
converted to integral types. But if you read "is convertible to **an** integral
type" as meaning unambiguously convertible to exactly one integral type, then
that's not true for FP types.

I did add tests for PR 87982 that FP types can be used, but I don't think there
were any pre-existing tests, and maybe nobody needs that.

I could retain support for real FP types, but reject your testcase, like this:

  constexpr long long
  __size_to_integer(floating_point auto __n) { return (long long)__n; }

But maybe I should just drop the FP overloads.

[Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107092

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
https://cplusplus.github.io/LWG/issue3213 is relevant, but we didn't address
the ambiguity question.

[Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107092

--- Comment #3 from Jiang An <de34 at live dot cn> ---
https://cplusplus.github.io/LWG/issue3793 has been submitted.

Such requirement was originally added by N0700
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1995/N0700.pdf), but
intented target types were unknown.