Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows)

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
> 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);