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: Stefan Monnier
Subject: Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows)
Date: Tue, 14 Jul 2009 14:18:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)

>> >   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?

I'm not sure about any piece of code, no.  Bugs are common.
But my reading of allocate_string_data starts by:

   /* Set up Lisp_String S for holding NCHARS characters, NBYTES bytes,
      plus a NUL byte at the end.  Allocate an sdata structure for S, and

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

make_uninit_multibyte_string calls allocate_string_data which does

  STRING_DATA (s)[nbytes] = '\0';

so the destination of the `bcopy' already has the terminating NUL.

So, I'm overall pretty sure our strings *should* always have a NUL right
after the last byte.  OTOH I'd be surprised if there isn't a bug
somewhere that makes it possible for some strings to occasionally fail
to have this terminating NUL (most likely, any bug that leads to
a crash could also lead to such a situation).


        Stefan




reply via email to

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