From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4B6A01F4C4 for ; Tue, 5 Nov 2024 18:07:41 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=XfCzwFC3; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=edEwggOm; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1730830028; bh=nuirmS4czqRKeqs1FcEJBYzWTF2fJfQuKuWM4+XiswA=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=XfCzwFC3yGsygEJu0ft4Myr8qaLPivVtw9EzIP9ZTVxpwf9FINsT7OqK1cDiKZSFL eRi5tJuJVRX0AUb6SlWoiJZ5seyWG7ajEzPYXM3RDhN+kG4P7yMZbJbY05csVzbbgb M5CnS2P94KMCaaqvocd6W1HyuyMFzhWjOQO2P2/Q= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 38B4144B72 for ; Tue, 5 Nov 2024 18:07:08 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=edEwggOm; dkim-atps=neutral Received: from s.wrqvtbkv.outbound-mail.sendgrid.net (s.wrqvtbkv.outbound-mail.sendgrid.net [149.72.123.24]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 947E344B24 for ; Tue, 5 Nov 2024 18:06:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=PHGaR2E05xEn6avc/Jg6BO27TgfML3cj7ZM/N9XmysY=; b=edEwggOmzyQ5RUUsM6ZOX2u8Sm8VwL6PtdIlqYvgeXBZPi7W7gwoTNezke8vEpnfJ+GN WDK0juYw/qRsGz7KOpLPLD5gdH3qNoYEFjkeQ6t5bkAy3r/09T/PdkH3AqNCewiK4eSiLo 0mMwENx7E5Uiek5gIuYfYLPVgQh+RT2W0llhjJWkM4X608th3klVf4qAh+kDIVtfHkQ/VS i9sZrB5Hf++SIPkb/coz7+vTfs5KczNtobOPY0LjSOf410BU9mHsop6o7H+PthShnx0CJK B98ot4aQv3F+HJhSnGq1d1x91uV+w/jf+cShInEpyZsu1p3fpodwcip7DCCvwotg== Received: by recvd-7cc7f7d978-zdspw with SMTP id recvd-7cc7f7d978-zdspw-1-672A5EBE-C 2024-11-05 18:06:54.469465283 +0000 UTC m=+4666248.849537375 Received: from herokuapp.com (unknown) by geopod-ismtpd-5 (SG) with ESMTP id fS8EVGE2QiinnzYZqdzu-g for ; Tue, 05 Nov 2024 18:06:54.433 +0000 (UTC) Date: Tue, 05 Nov 2024 18:06:54 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20869 X-Redmine-Issue-Author: javanthropus X-Redmine-Issue-Priority: Normal X-Redmine-Sender: byroot X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 96415 X-SG-EID: =?us-ascii?Q?u001=2EKmNZ1u3n1vIpO8NNTdp+Q9c0ai7potxbEDLMO7SOJO=2F4KkRUz0d23466m?= =?us-ascii?Q?naiq=2F5fmA4hb60MdRMUAwHZnjIWVFu=2FrqiBOz5c?= =?us-ascii?Q?nOvkBudsSTiMeJVzjAX9X0LtzynWstN68ZZqZBF?= =?us-ascii?Q?xSZ3iTNpm0nK1PR=2FZNFM5ZLiZCIj7Mf2WiIGX68?= =?us-ascii?Q?mQbdr8zCAsFyUtwm5JtMksbSMTfyVVf41y05NcU?= =?us-ascii?Q?C1iyY5Ah2usOzsu6eMWcSEK8a1zMRKmnjgZ4a38?= =?us-ascii?Q?Z68yWE6hSE9N57+52i+muD8UuA=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: D5VOLGFEK75ZFBNF743VNLKDZVSSDRUE X-Message-ID-Hash: D5VOLGFEK75ZFBNF743VNLKDZVSSDRUE X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119749] [Ruby master Bug#20869] IO buffer handling is inconsistent when seeking List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "byroot (Jean Boussier) via ruby-core" Cc: "byroot (Jean Boussier)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20869 has been updated by byroot (Jean Boussier). Just a quick proof of concept that fixes the first case: https://github.com/ruby/ruby/commit/7481a12fef3df934ab0d9db7f8f2d36341a1562e But I think a lot more codepath would need to consider and update that new offset for the entire class of bug to be fixed. ---------------------------------------- Bug #20869: IO buffer handling is inconsistent when seeking https://bugs.ruby-lang.org/issues/20869#change-110412 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When performing any of the seek based operations on IO (IO#seek, IO#pos=, or IO#rewind), the read buffer is inconsistently cleared: ```ruby require 'tempfile' Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #ungetbyte as the first read buffer # operation uses a buffer that is preserved during # seek operations f.ungetbyte(97) # Byte buffer will not be cleared f.seek(2, :SET) f.getbyte # => 97 end Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #getbyte before #ungetbyte uses a # buffer that is not preserved when seeking f.getbyte f.ungetbyte(97) # Byte buffer will be cleared f.seek(2, :SET) f.getbyte # => 50 end ``` Similar behavior happens when reading characters: ```ruby require 'tempfile' Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #ungetc as the first read buffer # operation uses a buffer that is preserved during # seek operations f.ungetc('a') # Character buffer will not be cleared f.seek(2, :SET) f.getc # => 'a' end Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #getc before #ungetc uses a # buffer that is not preserved when seeking f.getc f.ungetc('a') # Character buffer will be cleared f.seek(2, :SET) f.getc # => '2' end ``` When transcoding, however, the character buffer is never cleared when seeking: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) # Character buffer will not be cleared f.seek(2, :SET) f.getc # => 'a'.encode('utf-16le') end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc f.ungetc('a'.encode('utf-16le')) # Character buffer will not be cleared f.seek(2, :SET) f.getc # => 'a'.encode('utf-16le') end ``` I would expect the buffers to be cleared in all cases except possibly when the seek operation doesn't actually move the file pointer such as when calling IO#pos or IO#seek(0, :CUR). The inconsistent behavior demonstrated here is a problem regardless though. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/