[Top][All Lists]
[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
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), (continued)
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Stefan Monnier, 2009/07/13
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/13
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Miles Bader, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Davis Herring, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Miles Bader, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), David Kastrup, 2009/07/15
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Haojun Bao, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows),
Stefan Monnier <=
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/09
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/09
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Eli Zaretskii, 2009/07/09
Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Chong Yidong, 2009/07/06