From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.seebs.net (mail.seebs.net [162.213.38.76]) by mail.openembedded.org (Postfix) with ESMTP id 5012C71B32 for ; Tue, 27 Mar 2018 20:20:26 +0000 (UTC) Received: from seebsdell (unknown [24.196.59.174]) by mail.seebs.net (Postfix) with ESMTPSA id 158832E892B; Tue, 27 Mar 2018 15:20:28 -0500 (CDT) Date: Tue, 27 Mar 2018 15:20:26 -0500 From: Seebs To: Andre McCurdy Message-ID: <20180327152026.335b4c2d@seebsdell> In-Reply-To: References: <20180326143107.48f153a5@seebsdell> <20180326160746.1dce7ae9@seebsdell> <20180326203209.2da967eb@seebsdell> <20180326210734.165ac038@seebsdell> <20180326234108.4b52c066@seebsdell> <20180327142230.15f1abf9@seebsdell> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: OE-core Subject: Re: pseudo: host user contamination X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 20:20:27 -0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 27 Mar 2018 13:12:19 -0700 Andre McCurdy wrote: > If you mean forwarding arguments through a wrapper without > interpreting them then I don't know what your concern is. Forwarding > arguments can be handled completely generically - for any architecture > and any syscall. See the musl implementation. My concern is that, strictly speaking, this is nearly all undefined behavior, and that reading more arguments than you were passed *does* explode on some C implementations. Possibly none of the ones musl is targeting. I'm trying to minimize assumptions that *could in principle* affect portability, such as "it's safe to grab an arbitrary pool of arguments with va_arg", or "it's safe to grab arguments with va_arg using different parameter types than were used to store them". Because assumptions like those periodically break when, for some inexplicable reason, someone ports to an architecture that isn't a VAX 11/780. We're already stuck with "duplicating library functions" as a risk. But so far, I don't think I have any code which is manipulating arguments in a way that violates the spec. Adding such code creates an additional risk, however small that risk may be in practice right now. > However the good news is that code in a syscall() wrapper doesn't need > to be any *more* aware of argument ordering than the C code calling > syscall(). In this particular case, if the code in gnulib calling > syscall(SYS_renameat2, ...) doesn't do anything architecture specific > then either it's not needed (and therefore also not needed in a > syscall() wrapper which wants interpret renameat2 syscalls) or there's > a portability bug in gnulib. ie there is no case where architecture > specific awareness is required in a syscall() wrapper but not in the > original C code which calls syscall(). Yes. Right now, I think my inclination is to make a renameat2() wrapper which fails. We did that for renameat() originally, and it was years before it actually came up, and I think it's premature to attempt the wrapper at a time when I *can't* write test code which compares it to the behavior of libc. -s