On Thu, 10 Apr 2003, Andrew Brown wrote:

> yes, i'm a bit slow on this.
>
> On Mon, Apr 07, 2003 at 04:41:15PM +0300, Klaus Klein wrote:
> >
> >Module Name:	src
> >Committed By:	kleink
> >Date:		Mon Apr  7 13:41:14 UTC 2003
> >
> >Modified Files:
> >	src/include: stdlib.h
> >	src/lib/libc/stdlib: getenv.3 setenv.c
> >Added Files:
> >	src/lib/libc/stdlib: __unsetenv13.c unsetenv.c
> >
> >Log Message:
> >1003.1-2001 has introduced unsetenv() which differs from the current
> >implementation in not permitting a "name=value" argument.
> >* Add a conforming __unsetenv13() and do function renaming for
> >  unsetenv(); preserve old symbol with old behavior.
> >* Make visible setenv() and unsetenv() for 1003.1-2001 feature selection
> >  macros; resolves PR standards/20479.
>
> 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...

Yes, but it's the version of the library, libc. libc is at major 12, thus
in version (major) 13, they will loose the extra numberstuff.

If they were systemcalls, they'd be based on the kernel version.

Take care,

Bill