* Fix FAT handling on Windows to match the DJGPP port's FAT handling.

* Fix a potential hole in readline if lines end in ^M (CRLF).
This commit is contained in:
Paul Smith 2000-11-17 06:59:08 +00:00
parent d5a04ee984
commit e5324a8c6a
3 changed files with 33 additions and 37 deletions

View File

@ -1,3 +1,16 @@
2000-11-17 Paul D. Smith <psmith@gnu.org>
* remake.c (f_mtime) [WINDOWS32]: On various advice, I changed the
WINDOWS32 port to assume timestamps can be up to 3 seconds away
before throwing a fit.
2000-11-17 Paul D. Smith <psmith@gnu.org>
* read.c (readline): CRLF calculations had a hole, if you hit the
buffer grow scenario just right. Reworked the algorithm to avoid
the need for len or lastlen at all. Problem description with
sample code chages provided by Chris Faylor <cgf@redhat.com>.
2000-10-05 Paul D. Smith <psmith@gnu.org>
* acinclude.m4 (AM_LC_MESSAGES): Remove undefined macro

36
read.c
View File

@ -2142,15 +2142,16 @@ readline (linebuffer, stream, flocp)
char *buffer = linebuffer->buffer;
register char *p = linebuffer->buffer;
register char *end = p + linebuffer->size;
register int len, lastlen = 0;
register char *p2;
register unsigned int nlines = 0;
register int backslash;
*p = '\0';
while (fgets (p, end - p, stream) != 0)
{
char *p2;
unsigned long len;
int backslash;
len = strlen (p);
if (len == 0)
{
@ -2164,51 +2165,42 @@ readline (linebuffer, stream, flocp)
len = 1;
}
/* Jump past the text we just read. */
p += len;
/* If the last char isn't a newline, the whole line didn't fit into the
buffer. Get some more buffer and try again. */
if (p[-1] != '\n')
{
/* Probably ran out of buffer space. */
register unsigned int p_off = p - buffer;
unsigned long p_off = p - buffer;
linebuffer->size *= 2;
buffer = (char *) xrealloc (buffer, linebuffer->size);
p = buffer + p_off;
end = buffer + linebuffer->size;
linebuffer->buffer = buffer;
*p = '\0';
lastlen = len;
continue;
}
/* We got a newline, so add one to the count of lines. */
++nlines;
#if !defined(WINDOWS32) && !defined(__MSDOS__)
/* Check to see if the line was really ended with CRLF; if so ignore
the CR. */
if (len > 1 && p[-2] == '\r')
if ((p - buffer) > 1 && p[-2] == '\r')
{
--len;
--p;
p[-1] = '\n';
}
#endif
if (len == 1 && p > buffer)
/* P is pointing at a newline and it's the beginning of
the buffer returned by the last fgets call. However,
it is not necessarily the beginning of a line if P is
pointing past the beginning of the holding buffer.
If the buffer was just enlarged (right before the newline),
we must account for that, so we pretend that the two lines
were one line. */
len += lastlen;
lastlen = len;
backslash = 0;
for (p2 = p - 2; --len > 0; --p2)
for (p2 = p - 2; p2 >= buffer; --p2)
{
if (*p2 == '\\')
backslash = !backslash;
else
if (*p2 != '\\')
break;
backslash = !backslash;
}
if (!backslash)

View File

@ -1170,21 +1170,12 @@ f_mtime (file, search)
FILE_TIMESTAMP adjusted_mtime = mtime;
#if defined(WINDOWS32) || defined(__MSDOS__)
FILE_TIMESTAMP adjustment;
#ifdef WINDOWS32
/* FAT filesystems round time to the nearest even second!
Allow for any file (NTFS or FAT) to perhaps suffer from this
brain damage. */
adjustment = (((FILE_TIMESTAMP_S (adjusted_mtime) & 1) == 0
&& FILE_TIMESTAMP_NS (adjusted_mtime) == 0)
? (FILE_TIMESTAMP) 1 << FILE_TIMESTAMP_LO_BITS
: 0);
#else
/* On DJGPP under Windows 98 and Windows NT, FAT filesystems can
set file times up to 3 seconds into the future! The bug doesn't
occur in plain DOS or in Windows 95, but we play it safe. */
adjustment = (FILE_TIMESTAMP) 3 << FILE_TIMESTAMP_LO_BITS;
#endif
/* Experimentation has shown that FAT filesystems can set file times
up to 3 seconds into the future! Play it safe. */
#define FAT_ADJ_OFFSET (FILE_TIMESTAMP) 3
FILE_TIMESTAMP adjustment = FAT_ADJ_OFFSET << FILE_TIMESTAMP_LO_BITS;
if (ORDINARY_MTIME_MIN + adjustment <= adjusted_mtime)
adjusted_mtime -= adjustment;
#endif