emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow a


From: Eli Zaretskii
Subject: Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows)
Date: Tue, 14 Jul 2009 06:18:32 +0300

> From: Stefan Monnier <address@hidden>
> Cc: Andreas Schwab <address@hidden>,  address@hidden
> Date: Mon, 13 Jul 2009 20:54:14 -0400
> 
> > Aha.  But it sounds like it's not just me who is confused.  Here's
> > just two examples:
> 
> >   From doc.c:
> 
> >       strp = SDATA (string);
> >       while (strp < SDATA (string) + SBYTES (string))
> 
> >   (why not "while *strp"?)
> 
> As said Andreas, this would stop at the first NUL, which may appear
> within the string.

But then a gazillion other places are buggy: we _do_ use SDATA(str) as
a C string, and pass it to functions that will stop examining the
string on the first null.  A random example:

  d = opendir (SDATA (Fdirectory_file_name (encoded_dir)));

What am I missing?

> >   From fileio.c:
> >       nm = (unsigned char *) alloca (SBYTES (filename) + 1);
> >       bcopy (SDATA (filename), nm, SBYTES (filename) + 1);
> >   (why +1? it potentially accesses memory beyond end of `filename's
> >   contents)
> 
> The +1 is precisely used to make sure we copy the terminating NUL.

That's not my reading of allocate_string_data.  Are you sure?

Anyway, if that's true, then again we have bugs in other places.  Like
this one:

  directory_nbytes = SBYTES (directory);
  if (directory_nbytes == 0
      || !IS_ANY_SEP (SREF (directory, directory_nbytes - 1)))
    needsep = 1;
  [...]
                  int nbytes = len + directory_nbytes + needsep;
                  fullname = make_uninit_multibyte_string (nbytes, nbytes);
                  bcopy (SDATA (directory), SDATA (fullname),
                         directory_nbytes);




reply via email to

[Prev in Thread] Current Thread [Next in Thread]