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).