[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: |
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);
- 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), Andreas Schwab, 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), Andreas Schwab, 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), Andreas Schwab, 2009/07/13
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), Chong Yidong, 2009/07/14
- Re: Willing to debug bug #3542 (23.0.94; File access via UNC path slow again under Windows), YAMAMOTO Mitsuharu, 2009/07/13
- 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 <=
- 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, 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