Subject: [clisp-list] exporting reader functions for slots? - rant on quality of Linux manpages

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Tue Apr 1 06:23:13 2003

Sam Steingold wrote:
>I cannot check that because even 
>(linux::putpwent (linux:getpwent) linux:stdout)
>crashes:

Here's a rant on random quality of Linux Manpage documentation, as I happen to experiment a little with Linux (instead of Solaris):

1. Please tell me, after reading the manpage(s), the extent of the validity of the pw_* string areas returned by getpwent() -- i.e. how long will these point to valid content?
 o until the next system call?
 o until the next call to getpwent()?
 o until the call to endpwent()?
 o program exit?
 o other?

At least, the Solaris manpages mention getpwent_r() which does not suffer from any of these underspecifications.

2. Please note the following differences between Solaris and Linux:
2.A: Solaris:
     The putpwent() function is the inverse  of  getpwent().  See
     getpwnam(3C).  Given a pointer to a passwd structure created
     by getpwent(), getpwuid(), or getpwnam(), putpwent()  writes
     a   line  on  the  stream  f [...]
Strict interpretation of this means that putpwent() behaviour is undefined when given an arbitrary pointer to memory not obtained from getpwent/getpwuid/getpwnam().
E.g. Sam's use of (linux::putpwent (linux:getpwent) linux:stdout)
is illegal on Solaris under this strict interpretation
(CLISP FFI day-2 level question: why?).
Linux:
  no such restriction is mentioned.
Of course, I'll bet it nevertheless works on Solaris.

2.B: Solaris:
     setpwent() sets (or resets) the enumeration to the beginning
     of  the  set  of  password entries.  This function should be
     called  before  the  first  call  to  getpwent().
Linux:
       The  getpwent()[...]   The  first time it is called it returns the
       first entry; thereafter, it returns successive entries.
  I found no notice of similar restriction
"should be called" (Solaris) means?
 - code not calling setpwent() has unspecified behaviour?
 - ... ?

3. Please tell me, after reading the manpage(s), if the following code is correct:
pwent = getpwent();
if (0 != errno) { perror...; abort(); }
/* at this point pwent holds either a valid entry or NULL for EOF -sure? */

This errno question is truly more general:
i) is errno guaranteed to be set to 0 after successful function execution?
ii) Or is it only legal to inspect errno after a function returned some error indication?
iii) Can/Will functions set errno only on error?

Thanks for your attention,
	Jörg Höhle.

---

From: Sam Steingold <[email-masked]>
Date: Tue Apr 1 06:55:34 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] exporting reader functions for slots? - rant on quality of Linux manpages"
> * Sent on Tue, 1 Apr 2003 14:34:51 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> Sam Steingold wrote:
> Here's a rant on random quality of Linux Manpage documentation, as I
> happen to experiment a little with Linux (instead of Solaris):

linux manpages are considered obsolete.
use info (in emacs, xterm or your web browser).

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
If I had known that it was harmless, I would have killed it myself.