On Tue, 27 Mar 2018 13:12:19 -0700 Andre McCurdy <armccu...@gmail.com> 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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core