Source-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src
Jason Thorpe <thorpej%wasabisystems.com@localhost> 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
Home |
Main Index |
Thread Index |
Old Index