unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* [PATCH] Small fixes in doc/ref/srfi-modules.texi; a couple other questions
@ 2003-05-03  3:04 Stephen Compall
  2003-05-05 15:56 ` Paul Jarc
  0 siblings, 1 reply; 2+ messages in thread
From: Stephen Compall @ 2003-05-03  3:04 UTC (permalink / 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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Small fixes in doc/ref/srfi-modules.texi; a couple other questions
  2003-05-03  3:04 [PATCH] Small fixes in doc/ref/srfi-modules.texi; a couple other questions Stephen Compall
@ 2003-05-05 15:56 ` Paul Jarc
  0 siblings, 0 replies; 2+ messages in thread
From: Paul Jarc @ 2003-05-05 15:56 UTC (permalink / raw)
  Cc: bug-guile

Stephen Compall <s11@member.fsf.org> wrote:
> 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 :).

access() is merely a waste of time in non-set?id programs.  They can
just do whatever they want to do without explicitly checking for
permission first; if there's a permission problem, the operation will
simply fail.  set?id programs should use access() because they have
more permissions than they sometimes want to use; the operation might
succeed when it ought to fail.


paul


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-05-05 15:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-03  3:04 [PATCH] Small fixes in doc/ref/srfi-modules.texi; a couple other questions Stephen Compall
2003-05-05 15:56 ` Paul Jarc

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).