From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 71B4825BDA for ; Tue, 23 Jan 2024 19:48:42 +0100 (CET) Received: from mout.web.de ([212.227.15.4]) by 9front; Tue Jan 23 13:47:33 -0500 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1706035648; x=1706640448; i=alexander.shendi@web.de; bh=hJLFmMfllLnLsjWC+oJZg3lUzWhPXW2MgWPZx8PSTbs=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To: References; b=MsDqUioPYujehv5WOZpWxzuD1Bi85/KkcMeDzXv1OveKB0ZRkO/YOZutaQVZftqD yA50gMJuNgwJ6z5gdwo/el0KQWiYHiWDGiuDUd8CcyeWr6HMd2BemakJch74Nv0tN UqFTGFd7qUw4LmylH3EEjW+Z8p8ZK5W1Mc5y7FbPMEaA3Kdnpt6aojYI3k/YCfKPR Ku2L51sSbDUYEMlwhr4it7PoLNfsKk1DmOJq7OKZBgFYav9boCVdujFUvY42Sh493 xkblvA1fxirXZ8XMDBH+d61rrW8CQxeD6ba47574eFcrGSqFK3qXr0UPX6Bml9vSO uRq02u2kyLXRjHSTag== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from [10.236.8.5] ([10.236.8.5]) by msvc-mesg-web002.server.lan (via HTTP); Tue, 23 Jan 2024 19:47:28 +0100 MIME-Version: 1.0 Message-ID: From: Alexander Shendi To: 9front@9front.org Cc: 9front@9front.org Content-Type: text/plain; charset=UTF-8 Importance: normal Sensitivity: Normal Date: Tue, 23 Jan 2024 19:47:28 +0100 In-Reply-To: References: X-Priority: 3 X-Provags-ID: V03:K1:eO6KwRVVsCB53O118eo/1ifhlay6guKi/E/8J5v6M+lnEVBJh+fVIXddGUjIXuh1tV6wG C02kF464/Wn/IhDqv3GRUVD+icoPuYqruOcAsC+VVuMlVNhUFuLU3409sk03aj1ThscdBkr3jOkP j2gMfGhLtwwI1sFiExermvYzhNNIWKxotUIo/b4PUpjn5tdhIahFMmZJFxNvEXif04JhpLAhLAIE MTni6vW5w2lgkeA8SWRjtCkQVOlwROPmCwCiKe+F3FCHTjyvb3YMSNbWjHlDq73tRvfaz+uwZ439 DU= UI-OutboundReport: notjunk:1;M01:P0:MHCP/cb87cY=;tuw2U9prLKMQI8R5PnCZSG/s6oI gkkUGYwxuQv7kgHwhZIkeAX1KT+isYV1+IiZEdiMWg3mBLsco/Y4N+hUHAeGNmymvsBY4lSJH eAJFZ0SzBSEv0vFFJz81zDI9dBbxLgXNoxtG5vJ676AlV6P07ETSMB3kIxp9wP+4QRlLf0BNu kUu/Oh8cEwZp7RO+BGckWWLqXkcyLt2tZfMRmJuFBnQxZZIMQUDWA6FpgxhOCwLFg1VIEj5NI L+BZSMBZqSSlOi7uoOEYRaqnHg9bIzaeH2mL18ZjegSPuH9sKTjoFnyhObEpFI/J4wmJ6Kd0A NYIlqn4odyhAnjtfSCmisRUnKaoxG0ZoxwifZTir19zvY04sQM1EiXTEGB5lLbgfg3np4PpdN AnmfvLj55/9p58onIWGkqT7FRsuTy+tbB9MrMsBNsCB/sT2thrHw/gerWLnEch5aI1ZGfn/x8 kGIRhyMfchyXyt4M8QTPzQiGLbnUL1FfNtkk/Z9phPYcCRoWc06L4R5Cd5oj/+vbTyaZx1v8K /62LXSaf0b7f/pg1U+Cf+M0xcxUsEL0YbNCy2ungIqS/GdddIGzGp6g403pOLaMG8S0+bTUYZ HtbKgljZuPC6G80VsDspw4DztacOse+rZyrm1VHfZTY2QNzfKrUBP5qpysCAJ4D5LTigUSj9i ex0wbtUfehWyaoJVeCF91ZlGaH3Kq1hak4ZdMeboHiDofJA1RMkwFUIay+20JyT6xUmIQ0NQR ccBu534lB/frtr+CWyWgGKfkM1UBcrOoREg1T+jmUwwv3LbCzH9tD2BLIfjPEIPdrue0Bg47R Dch0C7TTrHdBs/5SQmH0kdxQ== Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: ISO-certified app database Subject: Aw: Re: [9front] [PATCH] awk: don't write an extra NUL past the end of a block Reply-To: 9front@9front.org Precedence: bulk Hi, DISCLAIMER: i haven't seen either the code of 9front's awk or onetrueawk's code. However that doesn't keep me from speculating. I suspect the fields are st= ored as an array of NUL-terminated strings itself terminated by a NUL char= . So you would need to allocate n+2 bytes for the last field. > Gesendet: Dienstag, den 23.01.2024 um 18:50 Uhr > Von: "Jacob Moody" > An: 9front@9front.org > Betreff: Re: [9front] [PATCH] awk: don't write an extra NUL past the end= of a block > > On my linux machine: > # nawk is onetrueawk > ; dd 8192+0 records in > 8192+0 records out > 32768 bytes (33 kB, 32 KiB) copied, 0.00933006 s, 3.5 MB/s > > This works fine. No crash. I am not doubting this needs fixed, > I am doubtful of fixing it in this way being correct. It is still > not clear to me if there is some other input that is relying on > that extra line to be there. But it is clear that onetrueawk fixed > this using some other fix. > > We should figure out how they solved it and/or prove that the cases > in which those loops never run are impossible to hit. >