From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=mmcI=7H=suse.de=schwab@sourceware.org>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d])
	by sourceware.org (Postfix) with ESMTPS id 2EE183858C83
	for <libc-alpha@sourceware.org>; Wed, 15 Mar 2023 09:22:17 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2EE183858C83
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
	by smtp-out2.suse.de (Postfix) with ESMTP id 649351FD6F;
	Wed, 15 Mar 2023 09:22:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1678872136; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=m9ghEUetJdJj+Y0jMnAund4V+j5PKS4zX1QOQLwT/YM=;
	b=AxLYGSRrkVV8mx1AyCwmLI5qcFlZRXiFq6Te4j4HRoDpBEWpDQXte1E7Kt4Lw/v1k9st7Z
	Q2J5xmIBgsgfBs/0z4f2eCueFNOuGn8jyvVqD/ePOWNXFd3WRrNIX/KqMu2EAyyP7xio1P
	+Y3dqU3tpzzRrFL/Tq0gzKgI1HfOH5w=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1678872136;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=m9ghEUetJdJj+Y0jMnAund4V+j5PKS4zX1QOQLwT/YM=;
	b=6zVYVU9GDl2M6TNcEiIoxzpSxUe+l6xkIfv4MLwgPODLeX7fzyaDxxEMQ8j1x3bxVSgteN
	bC86PQum/q5EiXDA==
Received: from hawking.suse.de (unknown [10.168.4.11])
	by relay2.suse.de (Postfix) with ESMTP id 3E4C52C141;
	Wed, 15 Mar 2023 09:22:16 +0000 (UTC)
Received: by hawking.suse.de (Postfix, from userid 17005)
	id 2683B4A093A; Wed, 15 Mar 2023 10:22:16 +0100 (CET)
From: Andreas Schwab <schwab@suse.de>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Simon Chopin <simon.chopin@canonical.com>,  libc-alpha@sourceware.org
Subject: Re: UB status of snprintf on invalid ptr+size combination?
References: <CAOOWow1L2ZMXE6S5pd3uKvAeHNQXMPtjew42LbAiQE-Pnd2ULg@mail.gmail.com>
	<a5bda742-c534-f5a6-abba-39d29c26f01e@cs.ucla.edu>
X-Yow: LIFE is a never-ending INFORMERCIAL!
Date: Wed, 15 Mar 2023 10:22:16 +0100
In-Reply-To: <a5bda742-c534-f5a6-abba-39d29c26f01e@cs.ucla.edu> (Paul Eggert's
	message of "Tue, 14 Mar 2023 14:39:42 -0700")
Message-ID: <mvmy1nyz7w7.fsf@suse.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

On Mär 14 2023, Paul Eggert wrote:

> For example, it's valid for snprintf to be implemented this way:
>
>   int
>   snprintf (char *buf, size_t size, char const *fmt, ...)
>   {
>      char *buf_limit = buf + size;
>      ...
>   }
>
> even though this would have undefined behavior if BUF points to a
> character array smaller than SIZE.

Since it is part of the implementation it is irrelevant from the POV of
the standard.  The implementation does not have to abide to the C
standard, as long as it properly implements the interface constraints.

What matters is the wording of the standard.  The POSIX standard is more
explicit here: "with the addition of the n argument which states the
size of the buffer referred to by s."  Probably the C standard should be
clarified.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."