On Mon, 25 Feb 2019 at 18:27, Eugene Syromyatnikov <evgsyr@xxxxxxxxx> wrote: > > Hello, Michael. > > On Mon, Feb 25, 2019 at 12:55 PM Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> wrote: > [...] > > diff --git a/man3/exec.3 b/man3/exec.3 > > index 0d531e921..10f15f3dc 100644 > > --- a/man3/exec.3 > > +++ b/man3/exec.3 > > @@ -277,6 +277,13 @@ internally and were consequently not async-signal-safe, > > in violation of the requirements of POSIX.1. > > .\" https://sourceware.org/bugzilla/show_bug.cgi?id=19534 > > This was fixed in glibc 2.24. > > +.\" > > +.SS Architecture-specific details > > +On sparc/sparc64, > > +.BR execv () > > +is provided as a system call by the kernel > > +(with the prototype shown above) > > +for compatibility with SunOS. > > I think that the reference to this sparc-specific system call here > might be a bit misleading; one might assume that glibc, for example, > uses the execv(2) for implementing execv(3) on sparc/sparc64, and that > is not the case (as far as I can see). Good point. I added some text to exec(3) to point out that this is not the case. Architecture-specific details On sparc and sparc64, execv() is provided as a system call by the kernel (with the prototype shown above) for compatibility with SunOS. This function is not employed by the execv() wrapper func‐ tion on those architectures. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
