On Tue, 27 Mar 2018 13:52:28 -0700 Andre McCurdy <armccu...@gmail.com> wrote:
> On Tue, Mar 27, 2018 at 1:20 PM, Seebs <se...@seebs.net> wrote: > > 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. > Can you give some examples? Not specific ones off the top of my head, no. > For every architecture I'm aware of that supports Linux, reading more > arguments is going to mean reading more data out of the stack. It's > not going "explode" until you read far enough to reach beyond the > start of the stack. What other failure modes are there? There are weird calling conventions out there. For instance, "pass floating point values in registers, but integers on stack", or "pass first N arguments in registers", and so on. I don't know if any of them are active in stuff Linux supports, but I'm aware that this is an area where you can get really strange behaviors. It's undefined behavior for a reason. > ALL of the implementations of libc syscall() I've looked at in both > glibc and musl do BOTH of these things - either explicitly in C code > or effectively the same thing in assembler. Yes. > By trying to avoid them in a wrapper, you are holding yourself to a > higher standard than any of the underlying syscall() implementations. Well, yes. They're part of the implementation and can make assumptions about architecture because they're in a position to define architecture. I'm not part of the implementation, and I don't want to take on the workload of trying to track every possible architecture if there's any possible way I can avoid it. -s -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core