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 4B5EF3858C98 for ; Thu, 4 Apr 2024 19:53:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B5EF3858C98 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 4B5EF3858C98 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-f199.google.com (mail-yb1-f199.google.com [209.85.219.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-SIYNl2keNIOk_OfMEriusA-1; Thu, 04 Apr 2024 15:53:34 -0400 X-MC-Unique: SIYNl2keNIOk_OfMEriusA-1 Received: by mail-yb1-f199.google.com with SMTP id 3f1490d57ef6-dcdc3db67f0so2883603276.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=Dd+7LxAzX95z6xZIBW6Yr6mXmjReEIiNwXp/EFyRnGTqk7Aln6CnFleywppgles05z FV3nnPR62deKiH/FoW2h40KySQ6HznU7cWroztqdDnBm4O9dJPO+97ZeVmq+tV5BLtBY aDRmp2eFx0yomzg88AqSSXw8oTIu6KuPalmyhe21tHn5FMqKbft01dU6NlHIsXrG75tb IazvfeWwYr7f0ckhKeUityL+cE+5xKsPw82sTxe+iplMkhT/BK3ziNukMxniHyc56/74 ODjr7ary8W8XRO24RAaG5zW0kvQaAU9Ee1stQ3VxQAwsJYbv9nUn/7KEPil2kqF8huCP H8eg== X-Forwarded-Encrypted: i=1; AJvYcCUJsTQ9fOxu1dRs1MwZGXFO1gLDI+E4Q1Xzdrz6Mt80RMuOwJl5S5bC5t+lVIusToVBI+nQC2Mg6wlS08PEqc6DSQ3930o7rg== X-Gm-Message-State: AOJu0YzmN6PMunAh+jI5+MY93WjckddbnHHdRe//BxPRwLqKU+/a4/sL VIr4N+vWb4cGg6Lui0Agmu6cr7riPA5zw1sl+VxAQaqAGwA/YFOioU0z4qDT6zs3LXPN8Zc3eYN 0jL7rIZR0nf9VQVtVUUSPj4TOShVi/8RbdYKn8pwRKDxPO/8CRR8XuuAb/xgZaaVklSDpHowIwC xWeiuP7+T7kcFxeXqWPYjCr1xyFB/9ZQ== X-Received: by 2002:a05:6902:2b03:b0:dc7:4645:83ab with SMTP id fi3-20020a0569022b0300b00dc7464583abmr502381ybb.0.1712260414088; 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=-3.5 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.