Jason Thorpe <thorpej@wasabisystems.com> writes:

> On Thursday, April 10, 2003, at 10:50  AM, Andrew Brown wrote:
> 
> > why __unsetenv13()?  why not __unsetenv16() or __unsetenv17()?  i had
> > always assumed that the numeric suffix on a renamed function was
> > somehow indicative of the last release (or first release) that had the
> > new function...
> 
> It's really supposed to indicate the shlib major that the function
> would correspond to.  The "14" functions are really goofs when the
> policy was not well-defined.

Well, said "14" functions (syscall stubs) do have the advantage of
indicating which kernel release they correspond to.  While having a
single scheme is good, having a future __call13() actually take slot
SYS___call20 seems likely to cause the same kind of confusion.

A not-so-serious suggestion would be to encode both the shlib major
_and_ the kernel release in such a symbol name... :-)


- Klaus