Re: svn commit: r17645 - in trunk/subversion: libsvn_diff

lundblad@tigris.org writes:
> --- trunk/subversion/libsvn_diff/diff_file.c (original)
> +++ trunk/subversion/libsvn_diff/diff_file.c Tue Dec 6 03:11:59 2005
> @@ -1197,13 +1188,31 @@
>
> [...]
>
> +/* Return the first eol marker found in [BUF, ENDP) as a NUL-terminated
> + * string, or NULL if no eol marker is found. */
> +static const char *
> +detect_eol (char *buf, char *endp)
> +{
> + const char *eol = find_eol_start (buf, endp - buf);
> + if (eol)
> + {
> + if (*eol == '\n')
> + return "\n";
> +
> + /* We found a CR. */
> + ++eol;
> + if (eol == endp || *eol != '\n')
> + return "\r";
> + return "\r\n";
> + }
> +
> + return NULL;
> +}

Fascinating.

I realize it's heuristic anyway, but: if we find a CR in the very last
byte we're allowed to look at, then it's "equally" likely that the
next byte is LF as not... In other words, is there a compelling reason
to prefer "\r" over "\r\n" in the unknown case? Wouldn't it be more
consistent to return NULL? In other words:

   const char *eol = find_eol_start (buf, endp - buf);
   if (eol)
     {
       if (*eol == '\n')
         return "\n";

       /* We found a CR. */
       ++eol;
       if (eol == endp)
         return NULL;
       else if (*eol != '\n')
         return "\r";
       return "\r\n";
     }
   return NULL;

Or if not, shouldn't the bias at least be documented?

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org