From nobody Fri Mar 13 13:13:26 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fXQ0Z0PYkz6V699; Fri, 13 Mar 2026 13:13:34 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fXQ0Y4TXmz3ZVh; Fri, 13 Mar 2026 13:13:33 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.18.1/8.18.1) with ESMTPS id 62DDDQCv047524 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 13 Mar 2026 14:13:27 +0100 (CET) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.18.1/8.18.1/Submit) id 62DDDQ10047523; Fri, 13 Mar 2026 14:13:26 +0100 (CET) (envelope-from fuz) Date: Fri, 13 Mar 2026 14:13:26 +0100 From: Robert Clausecker To: Aymeric Wibo Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 4da237aee328 - main - alloca.3: Add entry about defining VLAs in same block as alloca() to BUGS Message-ID: References: <69b40cd1.27eba.de1cc3f@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69b40cd1.27eba.de1cc3f@gitrepo.freebsd.org> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Queue-Id: 4fXQ0Y4TXmz3ZVh X-Spamd-Bar: ---- Hi Aymeric, Am Fri, Mar 13, 2026 at 01:10:41PM +0000 schrieb Aymeric Wibo: > Avoid > .Fn alloca > with large unbounded allocations. > +.Pp > +The use of C99 variable-length arrays and > +.Fn alloca > +in the same function will cause the lifetime of > +.Fn alloca Ns 's > +storage to be limited to the block containing the > +.Fn alloca . > +For example, in the following snippet, > +.Va p Ns 's > +lifetime does not extend outside of the block, whereas it would've if > +.Va vla > +hadn't been defined or had been defined as a fixed-length array: > +.Bd -literal -offset indent > +char *p; > +{ > + const int n = 100; > + int vla[n]; > + p = alloca(32); > + strcpy(p, "Hello, world!"); > + printf("Inside: %s\\n", p); /* Valid. */ > +} > +printf("Outside: %s\\n", p); /* Undefined. */ > +.Ed I am unsure if we should document the behaviour of mixing VLAs and alloca() in the same function as being defined, as that binds us to support it in the future. I would be a lot more comfortable just documenting that behaviour is undefined if the two are combined in one function. Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments