unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Stephen Compall <s11@member.fsf.org>
Subject: [PATCH] Small fixes in doc/ref/srfi-modules.texi; a couple other questions
Date: Fri, 2 May 2003 22:04:10 -0500	[thread overview]
Message-ID: <200305022204.53383.s11@member.fsf.org> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

See the patch at
http://csserver.evansville.edu/~sc87/dist/guile-man-4S11.patch

First, a changelog.  Then, some things I'm not clear on from reading
the manual:

2003-05-02  Stephen Compall  <s11@member.fsf.org>

	* srfi-modules.texi (reduce): changed equivalent fold code to
	match srfi-1.scm.

	(filter): tied up hanging sentence.

	(alist-copy): Emphasized difference with "normal" list-copy.

	Various grammar fixes and a couple parenthesis closings.

Now, my questions, which you may or may not consider documentation
bugs:
^L
srfi-1: for-each: "each pair"...of what?  You can pass more than two
lists.
^L
Documentation for access?: correct me if I'm wrong, but the subr
appears to use the libc `access' function.  Here's what the GNU libc
manual says about that function:

       `access' is _only_ only appropriate to use in setuid programs.
    A non-setuid program will always use the effective ID rather than
    the real ID.

See libc.info, node "Testing File Access", for the full story.  This
is a caveat for the usage, if it really is only only appropriate for
setuid programs.  But since the ruid == euid etc. in non-set?id
programs, I don't see the problem at first glance (though it could
conceivably cause problems in set?id programs :).  It's just something
I remember.
^L
It looks like read (scm_read) should return eof-object if at
end-of-file.  I believe the documentation should say that, and that
read-error occurs if there's another problem (though this may seem
obvious).

- -- 
Stephen Compall - Also known as S11001001
DotGNU `Contributor' -- http://dotgnu.org
Jabber ID: sirian@theoretic.com

Developing non-free software is mistreating other people. So don't
make a living that way. Find some other way to make a living. A way
that involves ethical behavior.
	-- RMS

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+szG12AceYinZ4EgRAqdyAJ98BLI4ehXz10ZMwv3ETXPNdHR4JQCfeIXn
0YbytHbve6EIorZON58OvsY=
=IUqr
-----END PGP SIGNATURE-----



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


             reply	other threads:[~2003-05-03  3:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-03  3:04 Stephen Compall [this message]
2003-05-05 15:56 ` [PATCH] Small fixes in doc/ref/srfi-modules.texi; a couple other questions Paul Jarc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200305022204.53383.s11@member.fsf.org \
    --to=s11@member.fsf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).