On Wed, Aug 09, 2017 at 03:14:49PM -0400, DJ Delorie wrote: > > "Dmitry V. Levin" <l...@altlinux.org> writes: > > This "= 0" has been printed all these years, so it's quite logical to > > suppose that the user expects to see "= 0" and might be quite surprised > > to see something else like "= 11" instead. > > Well, it *used* to print 11, I suppose 0 is better than 11 :-)
I agree, 0 is definitely better than 11 in this context. :) > >> Where in any of the traced > >> programs is that "= 0" available for inspection? > > > > It's in the register. On x86_64 it's %rax, on s390 it's %r2, etc. > > It's not about whether they expect to see "= 0" vs "= 11" - it's about > whether they expect to see *anything at all*. I bet they do. > I mean, at the C program level, does the user have access to that? Yes, using __asm__ extension, but it's hardly the C program level. > Should we be implying that execve() *returned* to the user's program? It's returned to userspace, but in case of successful invocation the return code is rather presented to the new program rather than returned. > By using a syntax that implies return of control to the caller, we may > be confusing the user into thinking that the exec failed, but returned a > zero to their program. > > We could add some other way of indicating success that doesn't imply > control was returned to the caller, like printing " (success)" instead > of " = 0" there. If the kernel supports PTRACE_EVENT_EXEC (modern kernels do), we can distinguish the case when execv() succeeded with return code 0 (or 11 or whatever else) from the unlikely case when execv() failed with return code 0 (or 11 or whatever else). I suppose these details would confuse users rather than make things more clear, though. -- ldv
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel