From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 498403816E2 for ; Sun, 8 Feb 2026 22:49:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770590946; cv=none; b=ewrqWilkdPyP9ZYD6vJpukjNFHUS1Iw9+A0RjOv2K1ilbGlJvz1d/4n7yUs7hb0Lu8vwwYxUGkFbQH0Fq+YTMXaLEQuvIKsTNNcBM7I3E/EFv8QrgFlX79fdfrr7/+hapjCETZBSIcBYEy00MHCOet+JSIzJ903Yzd51i91z1Qs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770590946; c=relaxed/simple; bh=jFo+xmFH4gPweztY/qdzEJ3lZFYjcalJubbs1oAyp/s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=W4MZ0++O13mXJuFmMnZMPRCWRBS2CUlElTZlnZemc4/TFIvuolj1fr2ljzV1zdKX56/T1sEscEA0x3YPRKgRp2L8BUm5fVzdIqm5kJqqBQ/PQJsSXxhNA3R8nbGxhZzAVwAYwKettb2kXiS7X9lCWFJM6NnVlJLGF8sezP/0eLQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gPZlxOx3; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gPZlxOx3" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4801c2fae63so31046975e9.2 for ; Sun, 08 Feb 2026 14:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770590945; x=1771195745; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=l0g5FAAWjSUJi2BBv3TyhTx1SYN1b7RP8oPZIQWkRXE=; b=gPZlxOx3GsEBopHYuVobTO428FJvuzePMaROkR+MuT+xj+AAzgvzTgaUEmKafOAw/V EtgTDNZ6wu6d9YyQwW7uUvNjQXlzksmQwaY+P7kG1EvT6TVA9+P0942D4MONd1fIyrsX AlD7YQ8yCXHwfGawlFK23LC1dDS8WCMHWai+N2Hr6sBNe1O3aluEVgDEhc0+DPPCidx2 Qn/O4gJp/k0cSozjfm0GFyxcUavMmWXXa5Xzg+SlDSunRI2X49Rik4m0ezAsAwDxd/1T ZN+La6/GXcGswyHzkZEmlUGhA87QLkRv+9lSs5Ln7G0AjGC+uVFt9cXfSSf3kWGatPOG 85/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770590945; x=1771195745; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=l0g5FAAWjSUJi2BBv3TyhTx1SYN1b7RP8oPZIQWkRXE=; b=Q7McWMwwPKOdSoNQx08qwpGx9ZSDXJs/0sGtVArwiLWT5stvaPx1hTP3RZHSag7/xK kGEQmMAi4onWdNMLt4+CWqL1jo8jD3msKdpbq1Zq7GUYoU6pcnx3za5gFw4LdJJ5onUA gEekmJu5Vi58mSLAawlMKGIFgZa0OApmRHIdvnKE0d9de5eoU70fL3e6x4KRYdF7IRia JdIQzwpscWuHpIw7ekPrCQp8BjY4lTHN4WiGfl47pZdxidaFgrw5+PiGCaFBkBnlVKCD RM4vFRCQr4iealkeilNyPVo01KxTwpZd3S/so3UlOr9oCcaTwOyFv2z4Jj8BwWSL3ULd TrUw== X-Forwarded-Encrypted: i=1; AJvYcCXGtMNTiA4pPuWLeC/yStvo0j+C1YSG1YTVZnI+ZISJUY3T7yQGp1g1G/baOAmzDkGJwqbhbL6bbsCdN7Q=@vger.kernel.org X-Gm-Message-State: AOJu0YzfxqvkyS6uDR92xIp3wqNHG53NMpf6Po7lQrlqp0B0GJTrG1Ri FJ4qdpwPCjlt0X2adqj0hn4c9tMHofZOawUYlPOqRs5PPLACvsmrbgaE X-Gm-Gg: AZuq6aIUReIMBREF/KQ9U3a9Nj7kaWivHi3qGw4jfaKu6szmBVyaGC5BpqUJQW8i8ip fjDH2jqMFnmH5j8YD7dT5l5nxD0+X7eHB5RyWQ5T7XwY4PMx8RQQMHq0y2CxC7PtAEs20Qax16N QDDBZwv6vkzzfMLz7YOUo3U/y6r3fAcKHKDe0OLeXQPbAq8jc/pgilagAxEZAwzAEAkzw2dIVeY VzCeD6jGOCUOwbVQkK7kmDM1IUqqZqEW6ChOjlkOmA8+ngxwUBespirPJgONZrIgZ/Uky+PpgqV IkDRZxrSS2nw7+qGEtSvXVrX7HDSWHqeNLRbG4zcpVzetdHUD6ioA6exLHU3+3AChy+Hd+hyhnN /E6GokxeFAjBliT6N+a3TBCzvSQcs1DvyQs6YuUnt3dMz+vkis7RkZIo2L+pm1UlakXlyYM/8Ch WJhoPduQIcrjgYza6yJAe/EM2IbluJ14XKpjWkWbJEf7TEPkos0b27 X-Received: by 2002:a05:600c:a08:b0:480:4d37:e742 with SMTP id 5b1f17b1804b1-483201dd276mr126887825e9.10.1770590944529; Sun, 08 Feb 2026 14:49:04 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-436296b2ed9sm22769191f8f.5.2026.02.08.14.49.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Feb 2026 14:49:03 -0800 (PST) Date: Sun, 8 Feb 2026 22:49:02 +0000 From: David Laight To: Willy Tarreau Cc: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , linux-kernel@vger.kernel.org, Cheng Li Subject: Re: [PATCH v2 next 02/11] tools/nolibc/printf: Move snprintf length check to callback Message-ID: <20260208224902.649c0cc3@pumpkin> In-Reply-To: References: <20260206191121.3602-1-david.laight.linux@gmail.com> <20260206191121.3602-3-david.laight.linux@gmail.com> <20260207232825.56b77d38@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 8 Feb 2026 16:12:59 +0100 Willy Tarreau wrote: .... > > > Here we certainly can unconditionally write the trailing zero. > > > > Writing the zero then overwriting it with 'no bytes' is too subtle (even for me). > > I'm sure you'd have wanted a big comment :-) > > Yes definitely! > > > > Bingo, we're > > > saving 9 bytes on x86_64 by moving it above. And even 17 bytes by dropping > > > the test on size and updating the state after the memcpy: > > > > > > if (size >= state->size) { > > > if (state->size <= 1) > > > return 0; > > > size = state->size - 1; > > > } > > > *state->buf = '\0'; > > > memcpy(state->buf, buf, size); > > > state->buf += size; > > > state->size -= size; > > > > That starts relying on the compiler assuming that the memcpy() can't > > be writing to state->buf and state->size. > > I'm not certain it can assume that in the callback function > > (With or without 'strict aliasing'). > > There's nothing to assume, the code is absolutely valid. We developers > have to do the correct thing and not suspect the compiler could do bad > things in our back, but as long as we're not passing state->buf pointing > to state, there's no such risk of aliasing. Right, there won't be aliasing, the compiler might be able to detect that it can't happen here because it can see all of the references to the relevant structures. But I think that if the functions weren't all static the compiler wouldn't be able to make that assumption. That would mean it couldn't use CSE for state->buf and state->size which would make the code larger (esp. on non-x86 where it can't do add-to-memory). Thinks (bad sign)... Was the saving on x86 because it did add/sub to memory rather than a register add/sub followed by a memory write? So for pretty much everything else (except m68k) you get a read/add/write sequences after the memcpy() which are larger (and slower). So you win on x86 and lose everywhere else. (m68k may not hace any callee saved register - so will have to spill to stack across a real memcpy() call.) There is another issue that (IIRC) technically memcpy(buf, NULL, 0) is UB. (This might be for some cpu (vax?) that trap when a NULL pointer is loaded into an address register.) I can image clang detecting that path and just deleting all the code. (Or doing something else equally unexpected.) If you care about that the 'if (size)' has to stay. (Or other changes done so that the pointer isn't NULL.) David