From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 4BA083858C52 for ; Thu, 4 Apr 2024 19:53:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4BA083858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4BA083858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712260418; cv=none; b=Luc5VKZMS6H7wzz9UThd9BYyB5WDmDhwpCy5a9viDKOUBnWDfsgFh7boeAdrix0MgiaWDeZR/BySeVaONDuVL7+u8UEbuz9vjTFL9gcnIFyAyoFqgf4uJCU2za9afQtgwfWA9aUNeotgEMykN/FI0QcQMMVjUeSxTlEOPZZa8qQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712260418; c=relaxed/simple; bh=EVlKgX3F4nr0IFM+8VruhpMLizG/psNiP/9WdmWtwUI=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=v9qqwGf3c5Ya/7qlk0X6tY3i7kQ3OmslDH0VCWUUoXlOWzMo1AgS5yf71gaQRrLzC5qKd+Xo+PkVl67HTwx+pHIhNYbNYOyxzsxKgQElp5uQdXKfc1zGteBKB/EfwOlHU0EaMh0kHtXe6gJexOrVuQUfUxc/S4jcWMEQUG6JywU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712260415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dRXdHDgI4Fq6zeUY+C3yjwPwGsHCi4L/LT7b9zdviY4=; b=BOkusbJMJq7ZuIm++4jnohWWNnVG+fRA/XFc5TVBDP3HQEF5xvnqtwhoLNBx06P9lmMnR6 NPp70DCfS7OWsR6jxCXrMOHRaNnHliumZUKT8WR1ducnzsJVWEQhfDqpuFjwWArrVmjI1I YQDLQqB1cF1br4Z3kVgP8cIlPz+1avE= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-509-78FugDs2PviXuSIfqFbOvQ-1; Thu, 04 Apr 2024 15:53:34 -0400 X-MC-Unique: 78FugDs2PviXuSIfqFbOvQ-1 Received: by mail-yb1-f200.google.com with SMTP id 3f1490d57ef6-dc691f1f83aso574585276.1 for ; Thu, 04 Apr 2024 12:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712260414; x=1712865214; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dRXdHDgI4Fq6zeUY+C3yjwPwGsHCi4L/LT7b9zdviY4=; b=uYziYOf0Vc9nnuK4oHgnOwHMwfI3c7vCYN/iNPVU5pcno+Z0SIscwbX2QMVhqr+Hnx OUCw3d72miTGkVlg2kIU/S6r9lQ5i+b+6inPHbprZ6Fv7O1tfrEUruJDt90bGcOklnYg P6xoh5vvu0K5S8bp6YH5GllkgoKzWjMR0KjFFZP7LOyZvreL6yH0meOT0BopvBZFxIJ7 r4EGLb605Ow3EnLQH8iXxD9xrnyZ51HsL6LFscCR8JWUo7Ddbxy7X2kuerdp3SM47fNO c87A8tJavir+PgmUsrXE9Vt6FUCiQXWPPcjVrRDQKA5yWo6Uw0WUwy+nCf/brpKR42Ch zfMw== X-Gm-Message-State: AOJu0YwgmTimKAk7LTnNfCJ2dIa6f4H2lVI8q2BZzRygwC1umo7JuxpV sCLZmDnCSqcisjjOaMfW/qQbSZg3XcsDtC9l4ozB1h+7ilciZyLLt19ORsO70vLJIs6RJWiL6wj D+OYzsvPJdvSSajgQAaxQwCZwOUJ2D5u/1QFcCbR4sfvgfiWs5/eKK/4k5OEFUmKvuCDT3rwTRk KfEQ/HGLXPW7uywv3HW9UyjW8CJxc= X-Received: by 2002:a05:6902:2b03:b0:dc7:4645:83ab with SMTP id fi3-20020a0569022b0300b00dc7464583abmr502379ybb.0.1712260414084; Thu, 04 Apr 2024 12:53:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG+oKahJe8TVvYgdVzLDWhZzA1hRX87oSrfIrS4osSwprAFRCrm2mkc5RMnGIg3q0AiYvPEpg1p7ls/dRW/owU= X-Received: by 2002:a05:6902:2b03:b0:dc7:4645:83ab with SMTP id fi3-20020a0569022b0300b00dc7464583abmr502372ybb.0.1712260413835; Thu, 04 Apr 2024 12:53:33 -0700 (PDT) MIME-Version: 1.0 References: <20240404153158.313297-1-jwakely@redhat.com> <19633866-184F-4E13-B05B-C3473946E2B9@googlemail.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 4 Apr 2024 20:53:18 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672] To: Iain Sandoe Cc: "libstdc++" , GCC Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 4 Apr 2024 at 17:55, Jonathan Wakely wrote: > > On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote: > Ulrich's suggestion is to allow the buggy user code to Just Work (for > all cases except (char)-1 on a platform where char is signed). That is > maybe the least surprising behaviour for users. > > On the other hand, I'm not sure we really want to support: > > cin.ignore(n, -10); > cin.ignore(n, -999); > cin.ignore(n, +999); > > What are these trying to do? Those are just nonsense arguments to this > function. But if we try to make the testcase in the bug report Just > Work, we end up also accepting (at least) the -10 case, because it's > indistinguishable from the char '\xf6'. Depending how we do it, we > might also make the other cases work, treating -999 as '\x19', and > +999 as '\xe7'. So maybe what we want is to add a new overload: basic_istream& ignore(streamsize n, char_type c) { return ignore(n, traits_type::to_int_type(c)); } This will only accept the stream's char_type, not -999 or +999, and will do the required conversion to int_type correctly, not as an implicit conversion. Calls that pass eof() will still select the other overload and do the right thing. Calls using a char (or for wstream, a wchar_t) will select the new overload. This new overload will make some calls ambiguous, e.g. ignore(1, 1L) compiles today, but would become ambiguous. That seems fine, since the second argument should not be type long (what is it even trying to do?) If that's a problem, we can make it a constrained template that only gets called for the exact char_type: basic_istream& ignore(streamsize n, same_as auto c) This would still Do The Right Thing for ignore(n, '\x80') but would not change the result of ignore(1, 1L) which would still select the original overload taking int_type for the second parameter. I think I'll raise this idea with the committee. For now though, I think my patch fixes the bug and conforms to the standard, and doesn't do anything inventive.