fork-the-syscall return semantics

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

In fork1(), in kern/kern_fork.c, there is code

        /*
         * Return child pid to parent process,
         * marking us as parent via retval[1].
         */
        if (retval != NULL) {
                retval[0] = p2->p_pid;
                retval[1] = 0;
        }

This is very old code; identical code appears as far back as 1.4T,
quite likely even farther back.  It appears the return semantics of
fork-the-syscall-trap (and related calls, like __vfork14) are a bit
odd: the parent returns <child,0> and the child returns <parent,1> (or
at least so a comment in the SPARC libc wrapper claims; I haven't dug
enough to find the kernel code where the child's return values are set
up).  But I see no reason for this, as the libc wrapper immediately
destroys the first return value in the child.

Does anyone happen to know why this was done?  So far I haven't found
any reason to not simply return the abstract return value in retval[0]
like most other syscalls that return a simple integer value, but for a
special case like this to have survived this long, I can't help feeling
there must be _something_ behind it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B