From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 09:26:35 2019 Received: (at submit) by debbugs.gnu.org; 19 Jun 2019 13:26:35 +0000 Received: from localhost ([127.0.0.1]:46213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdabj-000330-Hv for submit@debbugs.gnu.org; Wed, 19 Jun 2019 09:26:35 -0400 Received: from lists.gnu.org ([209.51.188.17]:52448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdVpR-0001cb-3H for submit@debbugs.gnu.org; Wed, 19 Jun 2019 04:20:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42779) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdVpQ-0000Jd-1p for bug-coreutils@gnu.org; Wed, 19 Jun 2019 04:20:25 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, FROM_EXCESS_BASE64 autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdVpP-0000dL-4T for bug-coreutils@gnu.org; Wed, 19 Jun 2019 04:20:24 -0400 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]:34080) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hdVpP-0000ce-03 for bug-coreutils@gnu.org; Wed, 19 Jun 2019 04:20:23 -0400 Received: by mail-io1-xd2b.google.com with SMTP id k8so6055539iot.1 for ; Wed, 19 Jun 2019 01:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=WWsSC0WNSt00fB/mWZZxKENeg4NNNSodMr137d84Zy0=; b=dWKF3DZNlxESy1Xbs646RD587jhmOwAOIXg7FAm+u45Jrjio6PWz7VMCl6TsaTnw1U +Gu1Bs0A7LfY4uCnDySEOXrHmT0OFBrUWSIs5ZAK+SK88zZ/34lwbExLZ0N5F771STBF +G2Ez+BYzwW88jTicKqGMzWk11DXqZvYSQ4Ua6qnAFmZ/+pxjG/CwuxECt6RY5cEoA03 CIh37TvFk3CqxnJez3hLGGHslQlzpBEhv5beSsH+VVUyZk1CFBvDv8QBvF2257qNyf9u 1x/hwNGQx2dQ3Hlw/B5JuOSPtOW4pueX/6fEnx2NxeJWgnJjv2GSefRHQ8K4VUf/l+rr tfUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=WWsSC0WNSt00fB/mWZZxKENeg4NNNSodMr137d84Zy0=; b=XTTWQbvtdZV0NZfSthWLp35VEsLJmDhWjblqeYpsM+up10MiWPB6gxcwyyYeh35hG4 2WvxrTo09P0mMaiRm/bEuv2k53q+4RYsPS1kRt/PMTsvi4DG1FFoxhDoRxW86REBCpTx htx8sCcpSAl1EVkyU4fUbpbuVpKatwwQeDNvQUPRfyeEXMQ4pxVMApmJ1VW/RCHN3/yL rOkAFBnSiUhkRSHs/ib7syOOfxzNBrLBf4gioeRHH+l/HC7+Yh4Sdw5u+HADq+ImfEok wLEFRlZoMh0yXpc7A05CtCfA3zPb6h6vzYqRBjr/3sC74a7y713pddpI8S25Uo4Sw6C/ 0lXQ== X-Gm-Message-State: APjAAAWxJlZ1BiEbAhzGOA10SU4U2IWyiQpy+tHiKUfWYREhx6MCwntR MiE6kn23rsTnoK0LaSvNJKvhr5xKHTgPTI2ZHT6aese9 X-Google-Smtp-Source: APXvYqy63wV2v3ffAnqZ0oqZkbXR500IEdPRg5RKTBl+PmyV1zZ5zA6zHVjtqYWnNGBFdd4tGlw0aFaYs0Pr1gIamtY= X-Received: by 2002:a5d:9613:: with SMTP id w19mr8969065iol.140.1560932421058; Wed, 19 Jun 2019 01:20:21 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?U3rFkXRzIMOBa29z?= Date: Wed, 19 Jun 2019 10:20:10 +0200 Message-ID: Subject: od --skip-bytes reads everything from the very beginning To: bug-coreutils@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2b X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 19 Jun 2019 09:26:34 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Dear List members, I've recently discovered that od "--skip-bytes" feature doesn't actually seek into the file but rather it reads everything from the very beginning until the given offset is reached. This can be problematic in two cases: - when speed matters, and - when parts of the file is read-protected (like in the case of /dev/mem when CONFIG_STRICT_DEVMEM=3Dy, which is usually the case). In this example od will reach an area in /dev/mem which is read-protected (even for root) and will report back EPERM before it could reach the requested, and allowed, memory area. The error report will be misleading since the resulting EPERM is not because the requested area is protected (as suggested by the error message) but because of the inner mechanics of the program. In contrary, hexdump jumps to the address directly. You can test it by running the following two commands: - strace hexdump --skip 0xFE000124 --length 1 /dev/sda - strace od --skip-bytes 0xFE000124 --read-bytes 1 /dev/sda I don't know whether this behaviour is intended but if so, could you please expand the documentation a little bit with this additional information? od version: od (GNU coreutils) 8.30, openSUSE Tumbleweed, x64 Thank you and all the best, =C3=81kos From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 15:42:36 2019 Received: (at 36291) by debbugs.gnu.org; 19 Jun 2019 19:42:36 +0000 Received: from localhost ([127.0.0.1]:47441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdgTb-000071-PC for submit@debbugs.gnu.org; Wed, 19 Jun 2019 15:42:36 -0400 Received: from mail.magicbluesmoke.com ([82.195.144.49]:33168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdgTa-00006s-Gr for 36291@debbugs.gnu.org; Wed, 19 Jun 2019 15:42:35 -0400 Received: from localhost.localdomain (unknown [109.79.94.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.magicbluesmoke.com (Postfix) with ESMTPSA id 68858999D; Wed, 19 Jun 2019 20:42:32 +0100 (IST) Subject: Re: bug#36291: od --skip-bytes reads everything from the very beginning To: =?UTF-8?B?U3rFkXRzIMOBa29z?= , 36291@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: Date: Wed, 19 Jun 2019 20:42:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36291 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 19/06/19 09:20, Szőts Ákos wrote: > Dear List members, > > I've recently discovered that od "--skip-bytes" feature doesn't > actually seek into the file but rather it reads everything from the > very beginning until the given offset is reached. > > This can be problematic in two cases: > - when speed matters, and > - when parts of the file is read-protected (like in the case of > /dev/mem when CONFIG_STRICT_DEVMEM=y, which is usually the case). In > this example od will reach an area in /dev/mem which is read-protected > (even for root) and will report back EPERM before it could reach the > requested, and allowed, memory area. The error report will be > misleading since the resulting EPERM is not because the requested area > is protected (as suggested by the error message) but because of the > inner mechanics of the program. > > In contrary, hexdump jumps to the address directly. > > You can test it by running the following two commands: > - strace hexdump --skip 0xFE000124 --length 1 /dev/sda > - strace od --skip-bytes 0xFE000124 --read-bytes 1 /dev/sda > > I don't know whether this behaviour is intended but if so, could you > please expand the documentation a little bit with this additional > information? > > od version: od (GNU coreutils) 8.30, openSUSE Tumbleweed, x64 > > Thank you and all the best, Similar issues were discussed in https://debbugs.gnu.org/18621 (though od always only skipped in regular files). It's hard to get something applicable to all cases. We'd like to seek for the last two here: $ stat /proc/$$/io /sys/kernel/vmcoreinfo /dev/sda /dev/mem | grep Size Size: 0 Blocks: 0 IO Block: 1024 regular empty file Size: 4096 Blocks: 0 IO Block: 4096 regular file Size: 0 Blocks: 0 IO Block: 4096 block special file Size: 0 Blocks: 0 IO Block: 4096 character special file Maybe we should relax the cases we do read() for, and try to seek in block/character special files, falling back to read() where that fails? Note one can get the same functionality by combining dd like: dd bs=1 skip=$((0xFE000124)) count=1 if=/dev/sda | od or more efficiently for larger sizes like dd iflag=skip_bytes skip=$((0xFE000124)) if=/dev/sda | od --read-bytes=1 cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 21:52:12 2019 Received: (at 36291-done) by debbugs.gnu.org; 20 Jun 2019 01:52:12 +0000 Received: from localhost ([127.0.0.1]:47637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdmFH-0005Wf-S2 for submit@debbugs.gnu.org; Wed, 19 Jun 2019 21:52:12 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hdmFF-0005WO-0n for 36291-done@debbugs.gnu.org; Wed, 19 Jun 2019 21:52:10 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B29BA161DC4; Wed, 19 Jun 2019 18:52:02 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pxJ7KJVIk2YG; Wed, 19 Jun 2019 18:52:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BD9D9161DC9; Wed, 19 Jun 2019 18:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DMLcPmQkbGhb; Wed, 19 Jun 2019 18:52:01 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 9A077161D53; Wed, 19 Jun 2019 18:52:01 -0700 (PDT) Subject: Re: bug#36291: od --skip-bytes reads everything from the very beginning To: =?UTF-8?Q?P=c3=a1draig_Brady?= References: From: Paul Eggert Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ7ZfpDmKqfjRRGw/+Ij03dhYfYl/gXVRiuzV1gGrbHk+t nfrI/C7fAeoFzQ5tVgVinShaPkZo0HTPf18x6IDEdAiO8Mqo1yp0CtHmzGMCJ50o4Grgfjlr 6g/+vtEOKbhleszN2XpJvpwM2QgGvn/laTLUu8PH9aRWTs7qJJZKKKAb4sxYc92FehPu6FOD 0dDiyhlDAq4lOV2mdBpzQbiojoZzQLMQwjpgCTK2572eK9EOEQySUThXrSIz6ASenp4NYTFH s9tuJQvXk9gZDdPSl3bp+47dGxlxEWLpBIM7zIONw4ks4azgT8nvDZxA5IZHtvqBlJLBObYY 0Le61Wp0y3TlBDh2qdK8eYL426W4scEMSuig5gb8OAtQiBW6k2sGUxxeiv8ovWu8YAZgKJfu oWI+uRnMEddruY8JsoM54KaKvZikkKs2bg1ndtLVzHpJ6qFZC7QVjeHUh6/BmgvdjWPZYFTt N+KA9CWX3GQKKgN3uu988yznD7LnB98T4EUH1HA/GnfBqMV1gpzTvPc4qVQinCmIkEFp83zl +G5fCjJJ3W7ivzCnYo4KhKLpFUm97okTKR2LW3xZzEW4cLSWO387MTK3CzDOx5qe6s4a91Zu ZM/j/TQdTLDaqNn83kA4Hq48UHXYxcIh+Nd8k/3w6lFuoK0wrOFiywjLx+0ur5jmmbecBGHc 1xdhAFHOwU0ETIByZAEQAKaF678T9wyH4wjTrV1Pz3cDEoSnV/0ZUrOT37p1dcGyj/IXq1x6 70HRVahAmk0sZpYc25PF9D5GPYHFWlNjuPU96rDndXB3hedmBRhLdC4bAXjI4DV+bmdVe+q/ IMnlZRaVlm9EiMCVAR6w13sReu7qXkW9r3RwY2AzXskp/tAe4BRKr1Zmbvi2nbnQ6epEC42r Rbx0B1EhjbIQZ5JHGk24iPT7LdBgnNmos5wYjzwNlkMQD5T0Ydzhk7J+UxwA5m46mOhRDC2r FV/A0gm5TLy8DXjv/Esc4gYnYai6SQqnUEVh5LuV8YCJBnijs+Tiw71x1icmn6xGI45EugJO gec+rLypYgpVp4x0HI5T88qBRYCkxH3Kg8Qo+EWNA9A4LRQ9DX8njona0gf0s03tocK8kBN6 6UoqqPtHBnc4eMgBymCflK12eKfd2YYxnyg9cZazWA5VslvTxpm76hbg5oiAEH/Vg/8MxHyA nPhfrgwyPrmJEcVBafdspJnYQxBYNco2LFPIhlOvWh8r4at+s+M3Lb26oUTczlgdW1Sf3SDA 77BMRnF0FQyE+7AzV79MBN4ykiqaezQxtaF1Fy/tvkhffSo8u+dwG0EgJh+te38gTcISVr0G IPplLz6YhjrbHrPRF1CN5UuL9DBGjxuN35RLNVEfta6RUFlR6NctTjvrABEBAAHCwWUEGAEC AA8FAkyAcmQCGwwFCRLMAwAACgkQ7ZfpDmKqfjSrHA/+KzAKvTxRhA9MWNLxIyJ7S5uJ16gs T3oCjZrBKGEhKMOGX4O0GA6VOEryO7QRCCYah3oxSG38IAnNeiwJXgU9Bzkk85UGbPEd7HGF /VSeHCQwWou6jqUDTSDvn9YhNTdG0KXPM74aC+xr2Zow1O2mhXihgWKD0Dw+0LYPnUOsQ0KO FxHXXYHmRrS1OZPU59BLvc+TRhIhafSHKLwbXK+6ckkxBx6h8z5ccpG0Qs4bFhdFYnFrEieD LoGmnE2YLhdV6swJ9VNCS6pLiEohT3fm7aXm15tZOIyzMZhHRSAPblXxQ0ZSWjq8oRrcYNFx c4W1URpAkBCOYJoXvQfD5L3lqAl8TCqDUzYxhH/tJhbDdHrqHH767jaDaTB1+Talp/2AMKwc XNOdiklGxbmHVG6YGl6g8Lrbsu9NZEI4yLlHzuikthJWgz+3vZhVGyNlt+HNIoF6CjDL2omu 5cEq4RDHM44QqPk6l7O0pUvN1mT4B+S1b08RKpqm/ff015E37HNV/piIvJlxGAYz8PSfuGCB 1thMYqlmgdhd9/BabGFbGGYHA6U4/T5zqU+f6xHy1SsAQZ1MSKlLwekBIT+4/cLRGqCHjnV0 q5H/T6a7t5mPkbzSrOLSo4puj+IToNjYyYIDBWzhlA19avOa+rvUjmHtD3sFN7cXWtkGoi8b uNcby4U= Organization: UCLA Computer Science Department Message-ID: Date: Wed, 19 Jun 2019 18:52:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------E15C52EC56CDD0503BF83007" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 36291-done Cc: 36291-done@debbugs.gnu.org, =?UTF-8?B?U3rFkXRzIMOBa29z?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------E15C52EC56CDD0503BF83007 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 6/19/19 12:42 PM, P=C3=A1draig Brady wrote: > Maybe we should relax the cases we do read() for, > and try to seek in block/character special files, > falling back to read() where that fails? Sure, that's easy enough. I installed the attached patch and am marking=20 this bug report as done. --------------E15C52EC56CDD0503BF83007 Content-Type: text/plain; charset=UTF-8; name="0001-od-use-fseek-on-non-regular-files.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-od-use-fseek-on-non-regular-files.txt" RnJvbSBlYTM1Mzg0NGQ4NjQyYjU1MzNjYmM3MTNlMGNlYzQ2YWRkYmYzOTA3IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBXZWQsIDE5IEp1biAyMDE5IDE4OjQ2OjU3IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gb2Q6IHVzZSBmc2VlayBvbiBub24tcmVndWxhciBmaWxlcwpNSU1FLVZlcnNpb246IDEu MApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFu c2Zlci1FbmNvZGluZzogOGJpdAoKUHJvYmxlbSByZXBvcnRlZCBieSBTesWRdHMgw4Frb3Mg KEJ1ZyMzNjI5MSkuCiogTkVXUzogTWVudGlvbiB0aGlzLgoqIHNyYy9vZC5jIChza2lwKTog VHJ5IGZzZWVrIGV2ZW4gb24gZmlsZXMgdGhhdCBkbyBub3QgaGF2ZSB1c2FibGUKc2l6ZXMs IGZhbGxpbmcgYmFjayBvbiBmcmVhZCBpZiBmc2VlayBmYWlscy4KLS0tCiBORVdTICAgICB8 IDMgKysrCiBzcmMvb2QuYyB8IDggKysrKysrLS0KIDIgZmlsZXMgY2hhbmdlZCwgOSBpbnNl cnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL05FV1MgYi9ORVdTCmlu ZGV4IGQzMDcxMWJjNi4uZmQwNTQzMzUxIDEwMDY0NAotLS0gYS9ORVdTCisrKyBiL05FV1MK QEAgLTM2LDYgKzM2LDkgQEAgR05VIGNvcmV1dGlscyBORVdTICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLSotIG91dGxpbmUgLSotCiAKICoqIE5ldyBGZWF0dXJlcwog CisgIG9kIC0tc2tpcC1ieXRlcyBub3cgY2FuIHVzZSBsc2VlayBldmVuIGlmIHRoZSBpbnB1 dCBpcyBub3QgYSByZWd1bGFyCisgIGZpbGUsIGdyZWF0bHkgaW1wcm92aW5nIHBlcmZvcm1h bmNlIGluIHNvbWUgY2FzZXMuCisKICAgc3RhdCgxKSBub3cgdXNlcyB0aGUgc3RhdHgoKSBz eXN0ZW0gY2FsbCB3aGVyZSBhdmFpbGFibGUsIHdoaWNoIGNhbgogICBvcGVyYXRlIG1vcmUg ZWZmaWNpZW50bHkgYnkgb25seSByZXRyaWV2aW5nIHJlcXVlc3RlZCBhdHRyaWJ1dGVzLgog ICBzdGF0KDEpIGFsc28gc3VwcG9ydHMgYSBuZXcgLS1jYWNoZWQ9IG9wdGlvbiB0byBjb250 cm9sIGNhY2hlCmRpZmYgLS1naXQgYS9zcmMvb2QuYyBiL3NyYy9vZC5jCmluZGV4IDFhODk1 NDJlZS4uNzVhNDAyMDA0IDEwMDY0NAotLS0gYS9zcmMvb2QuYworKysgYi9zcmMvb2QuYwpA QCAtMTAzMyw2ICsxMDMzLDggQEAgc2tpcCAodWludG1heF90IG5fc2tpcCkKIAogICAgICAg aWYgKGZzdGF0IChmaWxlbm8gKGluX3N0cmVhbSksICZmaWxlX3N0YXRzKSA9PSAwKQogICAg ICAgICB7CisgICAgICAgICAgYm9vbCB1c2FibGVfc2l6ZSA9IHVzYWJsZV9zdF9zaXplICgm ZmlsZV9zdGF0cyk7CisKICAgICAgICAgICAvKiBUaGUgc3Rfc2l6ZSBmaWVsZCBpcyB2YWxp ZCBmb3IgcmVndWxhciBmaWxlcy4KICAgICAgICAgICAgICBJZiB0aGUgbnVtYmVyIG9mIGJ5 dGVzIGxlZnQgdG8gc2tpcCBpcyBsYXJnZXIgdGhhbgogICAgICAgICAgICAgIHRoZSBzaXpl IG9mIHRoZSBjdXJyZW50IGZpbGUsIHdlIGNhbiBkZWNyZW1lbnQgbl9za2lwCkBAIC0xMDQw LDggKzEwNDIsNyBAQCBza2lwICh1aW50bWF4X3Qgbl9za2lwKQogICAgICAgICAgICAgIHdo ZW4gc3Rfc2l6ZSBpcyBubyBncmVhdGVyIHRoYW4gdGhlIGJsb2NrIHNpemUsIGJlY2F1c2UK ICAgICAgICAgICAgICBzb21lIGtlcm5lbHMgcmVwb3J0IG5vbnNlbnNlIHNtYWxsIGZpbGUg c2l6ZXMgZm9yCiAgICAgICAgICAgICAgcHJvYy1saWtlIGZpbGUgc3lzdGVtcy4gICovCi0g ICAgICAgICAgaWYgKHVzYWJsZV9zdF9zaXplICgmZmlsZV9zdGF0cykKLSAgICAgICAgICAg ICAgJiYgU1RfQkxLU0laRSAoZmlsZV9zdGF0cykgPCBmaWxlX3N0YXRzLnN0X3NpemUpCisg ICAgICAgICAgaWYgKHVzYWJsZV9zaXplICYmIFNUX0JMS1NJWkUgKGZpbGVfc3RhdHMpIDwg ZmlsZV9zdGF0cy5zdF9zaXplKQogICAgICAgICAgICAgewogICAgICAgICAgICAgICBpZiAo KHVpbnRtYXhfdCkgZmlsZV9zdGF0cy5zdF9zaXplIDwgbl9za2lwKQogICAgICAgICAgICAg ICAgIG5fc2tpcCAtPSBmaWxlX3N0YXRzLnN0X3NpemU7CkBAIC0xMDU2LDYgKzEwNTcsOSBA QCBza2lwICh1aW50bWF4X3Qgbl9za2lwKQogICAgICAgICAgICAgICAgIH0KICAgICAgICAg ICAgIH0KIAorICAgICAgICAgIGVsc2UgaWYgKCF1c2FibGVfc2l6ZSAmJiBmc2Vla28gKGlu X3N0cmVhbSwgbl9za2lwLCBTRUVLX0NVUikgPT0gMCkKKyAgICAgICAgICAgIG5fc2tpcCA9 IDA7CisKICAgICAgICAgICAvKiBJZiBpdCdzIG5vdCBhIHJlZ3VsYXIgZmlsZSB3aXRoIG5v bm5lZ2F0aXZlIHNpemUsCiAgICAgICAgICAgICAgb3IgaWYgaXQncyBzbyBzbWFsbCB0aGF0 IGl0IG1pZ2h0IGJlIGluIGEgcHJvYy1saWtlIGZpbGUgc3lzdGVtLAogICAgICAgICAgICAg IHBvc2l0aW9uIHRoZSBmaWxlIHBvaW50ZXIgYnkgcmVhZGluZy4gICovCi0tIAoyLjIxLjAK Cg== --------------E15C52EC56CDD0503BF83007-- From unknown Sun Jun 22 00:43:17 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 18 Jul 2019 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator