[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
wrong GCPRO in openp ()
From: |
Kenichi Handa |
Subject: |
wrong GCPRO in openp () |
Date: |
Mon, 06 Feb 2006 21:43:04 +0900 |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) |
I've just got a bug report about wrong GCPRO in openp ().
The relevant code is this:
openp (path, str, suffixes, storeptr, predicate)
[...]
{
[...]
string = filename = Qnil;
GCPRO6 (str, string, filename, path, suffixes, encoded_fn);
As encoded_fn is not yet initialized here, there's a
possibility that it leads to crash in mark_object. As a
simple fix is to initialized it to Qnil, I've just installed
such a change.
But, the variable encoded_fn is used as this:
[...]
else
{
const char *pfn;
encoded_fn = ENCODE_FILE (string);
pfn = SDATA (encoded_fn);
exists = (stat (pfn, &st) >= 0
&& (st.st_mode & S_IFMT) != S_IFDIR);
if (exists)
{
/* Check that we can access or open it. */
if (NATNUMP (predicate))
fd = (access (pfn, XFASTINT (predicate)) == 0) ? 1 : -1;
else
fd = emacs_open (pfn, O_RDONLY, 0);
[...]
So, I think there's no need of GCPRO for encoded_fn. Eli,
it seems that you are the last one who changed the code
around here.
2002-03-29 Eli Zaretskii <address@hidden>
[...]
* lread.c (openp, Fload): Encode the file name before passing it
to `stat', `access', and `emacs_open'.
(openp): GCPRO the encoded file name. Don't recompute Lisp
strings unnecessarily.
Do you remember why you did this change?
---
Kenichi Handa
address@hidden
- wrong GCPRO in openp (),
Kenichi Handa <=