This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Dec 2005 16:11:18 -0000
- Subject: [Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
- References: <bug-25304-1186@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #12 from pcarlini at suse dot de 2005-12-08 16:11 -------
(In reply to comment #11)
> However, I'm looking at the pratical effect. If libstdc++ changes the
> return types (correcting the bug) then it will be an ABI breakage.
> If LWG considers and agrees on the enhancement, libstdc++ will have to
> change again the return types. At the end of the day we would have
> two ABI breakages with zero net benefit for existing libstdc++ users.
I share your concerns. Want to add a couple of thoughts:
1- When we broke the ABI to fix 16505, I think we did that with the spirit that
it was a, so to speak, "weak" breakage, because could possibly byte only people
using the return value, something not standard conforming. Indeed, we received
zero complaints, as I already remarked.
2- As I see the issue, it depends a lot on the actual timeframe of the possible
enhancement to the standard. I mean, if we are thinking about C++0x, seems
rather far in time. I think most of our users would not perceive our practice
as randomly going back and forward on something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304