From: Mikael Djurfeldt <mdj@mit.edu>
Cc: djurfeldt@nada.kth.se, Marius Vollmer <mvo@zagadka.de>,
Guile-Devel Mailing List <guile-devel@gnu.org>
Subject: Re: Strange code in modules.c
Date: Sun, 23 Nov 2003 13:11:13 -0500 [thread overview]
Message-ID: <xy7oev3ymym.fsf@chunk.mit.edu> (raw)
In-Reply-To: <3FBE9CE3.4080007@dirk-herrmanns-seiten.de> (Dirk Herrmann's message of "Sat, 22 Nov 2003 00:16:51 +0100")
Dirk Herrmann <dirk@dirk-herrmanns-seiten.de> writes:
> the following patch fixes a piece of code in modules.c which seems
> wrong to me. I am, however, not quite sure that I am not missing
> something. If there are no complaints I will submit the patch in the
> next couple of days.
>
> RCS file: /cvsroot/guile/guile/guile-core/libguile/modules.c,v
> retrieving revision 1.51
> diff -u -r1.51 modules.c
> --- libguile/modules.c 12 Sep 2003 15:11:09 -0000 1.51
> +++ libguile/modules.c 21 Nov 2003 22:27:29 -0000
> @@ -277,8 +277,7 @@
> module_variable (SCM module, SCM sym)
> {
> #define SCM_BOUND_THING_P(b) \
> - (!SCM_FALSEP(b) && \
> - (!SCM_VARIABLEP(b) || !SCM_UNBNDP (SCM_VARIABLE_REF (b))))
> + (SCM_VARIABLEP (b) && !SCM_UNBNDP (SCM_VARIABLE_REF (b)))
> /* 1. Check module obarray */
> SCM b = scm_hashq_ref (SCM_MODULE_OBARRAY (module), sym, SCM_UNDEFINED);
It looks like the old code takes care of two kinds of obarrays:
1. Those which bind identifiers to locations represented by hash buckets.
2. Those which bind identifiers to locations represented by variables
(in a hash bucket).
(The code assumes that variables aren't passed around as values on the
user level, which is probably wrong.)
I think Guile used to have both. The "system" obarrays (the ones
which were initialized early before booting the module system) was of
the first kind and module system obarrays was of the second kind.
You'd better check that this is no longer the case, and that *all*
bindings use variables. (That is of course the proper way.)
We should also be aware that the change you suggest introduces a kind
of backward incompatibility with regards to the module system. I
doubt that many people have relied much on the module system API, though...
Best regards,
Mikael
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2003-11-23 18:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-21 23:16 Strange code in modules.c Dirk Herrmann
2003-11-23 18:11 ` Mikael Djurfeldt [this message]
2003-11-27 22:36 ` Dirk Herrmann
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=xy7oev3ymym.fsf@chunk.mit.edu \
--to=mdj@mit.edu \
--cc=djurfeldt@nada.kth.se \
--cc=guile-devel@gnu.org \
--cc=mvo@zagadka.de \
/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).