From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84008 invoked by alias); 24 Jan 2018 17:53:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 83070 invoked by uid 89); 24 Jan 2018 17:53:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=Hx-languages-length:913, H*M:info, H*F:D*info X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 17:53:54 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1eePF8-0007va-MO; Wed, 24 Jan 2018 20:53:50 +0300 Date: Wed, 24 Jan 2018 18:35:00 -0000 From: Petr Ovtchenkov To: =?utf-8?Q?Fran=C3=A7ois?= Dumont Cc: "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: New istreambuf_iterator debug check Message-ID: <20180124205350.582a66ce@void-ptr.info> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg02049.txt.bz2 On Wed, 24 Jan 2018 17:39:59 +0100 Fran=C3=A7ois Dumont wrote: > Hi >=20 > =C2=A0=C2=A0=C2=A0 I'd like to propose this new debug check. Comparing w= ith non-eos=20 > istreambuf_iterator sounds like an obvious coding mistake. >=20 > =C2=A0=C2=A0=C2=A0 I propose it despite the stage 1 as it is just a new = debug check,=20 > it doesn't impact the lib in normal mode. >=20 > =C2=A0=C2=A0=C2=A0 Tested under Linux x86_64, ok to commit ? >=20 > Fran=C3=A7ois >=20 bool equal(const istreambuf_iterator& __b) const - { return _M_at_eof() =3D=3D __b._M_at_eof(); } + { + bool __this_at_eof =3D _M_at_eof(); + bool __b_at_eof =3D __b._M_at_eof(); + + __glibcxx_requires_cond(__this_at_eof || __b_at_eof, _M_message( + "Abnormal comparison to non-end-of-stream istreambuf_iterator")); + return __this_at_eof =3D=3D __b_at_eof; + } Looks strange for me. It is legal and possible that istreambuf_iterator will be in EOF state. -- - ptr