diff options
Diffstat (limited to 'manual')
| -rw-r--r-- | manual/locale.texi | 2 | ||||
| -rw-r--r-- | manual/nss.texi | 34 | ||||
| -rw-r--r-- | manual/users.texi | 5 |
3 files changed, 28 insertions, 13 deletions
diff --git a/manual/locale.texi b/manual/locale.texi index 1468a29..6128df7 100644 --- a/manual/locale.texi +++ b/manual/locale.texi @@ -376,7 +376,7 @@ as far as the system follows the Unix standards. @end menu @node The Lame Way to Locale Data, The Elegant and Fast Way, ,Locale Information -@subsection @code{localeconv}: It's portable but @dots{} +@subsection @code{localeconv}: It is portable but @dots{} Together with the @code{setlocale} function the @w{ISO C} people invented @code{localeconv} function. It is a masterpiece of misdesign. diff --git a/manual/nss.texi b/manual/nss.texi index f6293c0..282127c 100644 --- a/manual/nss.texi +++ b/manual/nss.texi @@ -151,7 +151,7 @@ individual service. Assume the service @var{name} shall be used for a lookup. The code for this service is implemented in a module called @file{libnss_@var{name}}. On a system supporting shared libraries this is in fact a shared library -with the name (for example) @file{libnss_@var{name}.so.1}. The number +with the name (for example) @file{libnss_@var{name}.so.2}. The number at the end is the currently used version of the interface which will not change frequently. Normally the user should not have to be cognizant of these files since they should be placed in a directory where they are @@ -337,7 +337,7 @@ the function in the module @smallexample - libnss_files.so.1 + libnss_files.so.2 @end smallexample @noindent @@ -358,8 +358,8 @@ access them. If a function is not available it is simply treated as if the function would return @code{unavail} (@pxref{Actions in the NSS configuration}). -The file name @file{libnss_files.so.1} would be on a @w{Solaris 2} -system @file{nss_files.so.1}. This is the difference mentioned above. +The file name @file{libnss_files.so.2} would be on a @w{Solaris 2} +system @file{nss_files.so.2}. This is the difference mentioned above. Sun's NSS modules are usable as modules which get indirectly loaded only. @@ -398,7 +398,7 @@ The actual prototype of the function in the NSS modules in this case is enum nss_status _nss_files_gethostbyname_r (const char *name, struct hostent *result_buf, char *buf, size_t buflen, - int *h_errnop) + int *errnop, int *h_errnop) @end smallexample I.e., the interface function is in fact the reentrant function with the @@ -511,10 +511,10 @@ sources and its development. The links between the C library and the new service module consists solely of the interface functions. Each module is designed following a specific interface specification. -For now the version is 1 and this manifests in the version number of the -shared library object of the NSS modules: they have the extension -@code{.1}. If the interface ever changes in an incompatible way, -this number will be increased---hopefully this will never be necessary. +For now the version is 2 (the interface in version 1 was not adequate) +and this manifests in the version number of the shared library object of +the NSS modules: they have the extension @code{.2}. If the interface +changes again in an incompatible way, this number will be increased. Modules using the old interface will still be usable. Developers of a new service will have to make sure that their module is @@ -524,7 +524,7 @@ Object Name) must also have this number. Building a module from a bunch of object files on an ELF system using GNU CC could be done like this: @smallexample -gcc -shared -o libnss_NAME.so.1 -Wl,-soname,libnss_NAME.so.1 OBJECTS +gcc -shared -o libnss_NAME.so.2 -Wl,-soname,libnss_NAME.so.2 OBJECTS @end smallexample @noindent @@ -581,7 +581,7 @@ a simple noop. There normally is no return value different to @var{NSS_STATUS_SUCCESS}. -@item enum nss_status _nss_@var{database}_get@var{db}ent_r (@var{STRUCTURE} *result, char *buffer, size_t buflen) +@item enum nss_status _nss_@var{database}_get@var{db}ent_r (@var{STRUCTURE} *result, char *buffer, size_t buflen, int *errnop) Since this function will be called several times in a row to retrieve one entry after the other it must keep some kind of state. But this also means the functions are not really reentrant. They are reentrant @@ -598,6 +598,11 @@ guaranteed that the same buffer will be passed for the next call of this function. Therefore one must not misuse this buffer to save some state information from one call to another. +Before the function returns the implementation should store the value of +the local @var{errno} variable in the variable pointed to be +@var{errnop}. This is important to guarantee the module working in +statically linked programs. + As explained above this function could also have an additional last argument. This depends on the database used; it happens only for @code{host} and @code{networks}. @@ -610,7 +615,7 @@ returned. When the service was not formerly initialized by a call to @code{_nss_@var{DATABASE}_set@var{db}ent} all return value allowed for this function can also be returned here. -@item enum nss_status _nss_@var{DATABASE}_get@var{db}by@var{XX}_r (@var{PARAMS}, @var{STRUCTURE} *result, char *buffer, size_t buflen) +@item enum nss_status _nss_@var{DATABASE}_get@var{db}by@var{XX}_r (@var{PARAMS}, @var{STRUCTURE} *result, char *buffer, size_t buflen, int *errnop) This function shall return the entry from the database which is addressed by the @var{PARAMS}. The type and number of these arguments vary. It must be individually determined by looking to the user-level @@ -626,6 +631,11 @@ to non-constant global data. The implementation of this function should honour the @var{stayopen} flag set by the @code{set@var{DB}ent} function whenever this makes sense. +Before the function returns the implementation should store the value of +the local @var{errno} variable in the variable pointed to be +@var{errnop}. This is important to guarantee the module working in +statically linked programs. + Again, this function takes an additional last argument for the @code{host} and @code{networks} database. diff --git a/manual/users.texi b/manual/users.texi index 562390c..28d390c 100644 --- a/manual/users.texi +++ b/manual/users.texi @@ -1882,6 +1882,7 @@ selected and then one can iterate over all entries in this netgroup. These functions are declared in @file{netdb.h}. @comment netdb.h +@comment BSD @deftypefun int setnetgrent (const char *@var{netgroup}) A call to this function initializes the internal state of the library to allow following calls of the @code{getnetgrent} iterate over all entries @@ -1906,6 +1907,7 @@ the @code{innetgr} function and parts of the implementation of the @code{compat} service part of the NSS implementation. @comment netdb.h +@comment BSD @deftypefun int getnetgrent (char **@var{hostp}, char **@var{userp}, char **@var{domainp}) This function returns the next unprocessed entry of the currently selected netgroup. The string pointers, which addresses are passed in @@ -1920,6 +1922,7 @@ value of @code{0} means no further entries exist or internal errors occurred. @end deftypefun @comment netdb.h +@comment GNU @deftypefun int getnetgrent_r (char **@var{hostp}, char **@var{userp}, char **@var{domainp}, char *@var{buffer}, int @var{buflen}) This function is similar to @code{getnetgrent} with only one exception: the strings the three string pointers @var{hostp}, @var{userp}, and @@ -1937,6 +1940,7 @@ SunOS libc does not provide this function. @end deftypefun @comment netdb.h +@comment BSD @deftypefun void endnetgrent (void) This function free all buffers which were allocated to process the last selected netgroup. As a result all string pointers returned by calls @@ -1951,6 +1955,7 @@ only interesting question is whether a given entry is part of the selected netgroup. @comment netdb.h +@comment BSD @deftypefun int innetgr (const char *@var{netgroup}, const char *@var{host}, const char *@var{user}, const char *@var{domain}) This function tests whether the triple specified by the parameters @var{hostp}, @var{userp}, and @var{domainp} is part of the netgroup |