From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 20265 invoked from network); 1 Dec 2023 12:34:19 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 1 Dec 2023 12:34:19 -0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by 9front; Fri Dec 1 07:32:56 -0500 2023 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 3F5FB580433 for <9front@9front.org>; Fri, 1 Dec 2023 07:32:55 -0500 (EST) Received: from imap53 ([10.202.2.103]) by compute5.internal (MEProxy); Fri, 01 Dec 2023 07:32:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=grimmwa.re; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1701433975; x=1701437575; bh=44PFwEj4o1qyUJg0+DNeNg3GG6SbXe3a2lC /H4WeeP8=; b=OHwTWOGk2gSBmStHt9A55KLLGNG2nGBinInUa3SYsglgml34EIi 1dGkTUDB7RZc0D6gtPRhPDZC0Vgi0bSbmQTvvTAPOgbqPtwLiPoD7eesIka8VzEE qRLTFfLYAU7dSpYjkMxeePJ4B0CaRKgP/j5amD6zFcOHd6+d/VsSM9CIoqYbg1Ky PdBAu3gRBAp0FHNwZRzeJ8o+Sv82l4xSoMVxQwhe4xQJr8FUoYgZ8UVby7Y/e4VW nXwvp6g6rAHtIG8u4exKrbtNKMYevIctxg6B5gyNmJYgb8jINJxKLf8rPacNK5zu bhXF8ZhoNqRSq14k58/LSw/5V6bubweLjxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1701433975; x= 1701437575; bh=44PFwEj4o1qyUJg0+DNeNg3GG6SbXe3a2lC/H4WeeP8=; b=B gdxHxw3uFAjm3q/Fn0wWJq9lpSENAy4A4Uf2O0LNSHJa6SjPJUivc6of2j0NUcsQ x2JJ5pAao7XmKqdLBF7H0yYK81l25iqawZbmjNYcnuD9/6C4afrcsBm/Up7JEcqf FhCoWK5kv6Huc6UGwJ8mPqorTjeLMaZFAoPoGV48G2CDHRS5shTfAqKaOYw6qVST DOeN3x8kTAYkkUilJ2KVTAp6twFxQYj8ehvKuP99IEjvIrv+EAtPkQehOjzKCXE2 6LYhFTgHjR/+hJ1lfZ9nhdaIc9s6C+08/34J0WMbQZDUDe/CSkkJUKdMC2OdiE5n QmqaVdNo1HJ2ijeCbbJKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiledggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepifhrihhmmhifrghrvgcuoehohhholhhirggssehgrhhi mhhmfigrrdhrvgeqnecuggftrfgrthhtvghrnhepteevlefhueffudeiveekgeegkefgud eiuedvteethfffkedutedvffehgeelledvnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepohhhohhlihgrsgesghhrihhmmhifrgdrrhgv X-ME-Proxy: Feedback-ID: id8b949c5:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE9523640069; Fri, 1 Dec 2023 07:32:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1178-geeaf0069a7-fm-20231114.001-geeaf0069 MIME-Version: 1.0 Message-Id: <963d0ca4-518a-40a1-b95a-bc96ed9595a6@app.fastmail.com> In-Reply-To: <37AED63CD461E005AD8BD7ABA842FBD3@felloff.net> References: <37AED63CD461E005AD8BD7ABA842FBD3@felloff.net> Date: Fri, 01 Dec 2023 12:32:34 +0000 From: Grimmware To: 9front@9front.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: progressive compliant callback-oriented self-signing DOM-scale dependency solution Subject: Re: [9front] [PATCH] Correct acid's rune size to 4 bytes Reply-To: 9front@9front.org Precedence: bulk Yeah so it does, I've updated my test case to include a rune that trigge= rs this bug (=F0=90=80=80, U+10000, lower 2 bytes are empty) and have a = fix for it, but before I do that I'm suddenly having second thoughts abo= ut the use of sizeof here for the rune string when I've just changed the= \r (single rune) case to use `get4` anyway. I think I want to switch this back to hardcoding 4 bytes instead of usin= g sizeof on the basis that a) the rune size is probably not going to cha= nge again any time soon b) if it *does* acid would then be inconsistentl= y wrong instead of consistently wrong c) consistency with the rest of th= e acid codebase. Opinions? On Wed, Nov 29, 2023, at 7:13 PM, cinap_lenrek@felloff.net wrote: >> if(buf[i] =3D=3D 0 && buf[i+1] =3D=3D 0) >> break; > > this seems still to assume 2 byte runes. > > -- > cinap