public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/107092] New: std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type
@ 2022-09-30  3:20 de34 at live dot cn
  2022-09-30 10:54 ` [Bug libstdc++/107092] " redi at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: de34 at live dot cn @ 2022-09-30  3:20 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type
  2022-09-30  3:20 [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
@ 2022-09-30 10:54 ` redi at gcc dot gnu.org
  2022-09-30 10:56 ` redi at gcc dot gnu.org
  2022-10-14  2:29 ` de34 at live dot cn
  2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-30 10:54 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type
  2022-09-30  3:20 [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
  2022-09-30 10:54 ` [Bug libstdc++/107092] " redi at gcc dot gnu.org
@ 2022-09-30 10:56 ` redi at gcc dot gnu.org
  2022-10-14  2:29 ` de34 at live dot cn
  2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-30 10:56 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/107092] std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type
  2022-09-30  3:20 [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
  2022-09-30 10:54 ` [Bug libstdc++/107092] " redi at gcc dot gnu.org
  2022-09-30 10:56 ` redi at gcc dot gnu.org
@ 2022-10-14  2:29 ` de34 at live dot cn
  2 siblings, 0 replies; 4+ messages in thread
From: de34 at live dot cn @ 2022-10-14  2:29 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-10-14  2:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-30  3:20 [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
2022-09-30 10:54 ` [Bug libstdc++/107092] " redi at gcc dot gnu.org
2022-09-30 10:56 ` redi at gcc dot gnu.org
2022-10-14  2:29 ` de34 at live dot cn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).