2013/3/20 Joe Mistachkin <sql...@mistachkin.com>:
> Actually, given the variety of possible text encodings, we know
> very little with absolute certainty.
That's true. The fact that NUL is no valid character in any
text encoding is an absolute certainty, but other assumptions
cannot be made.
> If I'm understanding you correctly, this will further complicate
> the code without much benefit.
I would propose to change the lines (4 x in src/diff.c)
flags |= LOOK_NUL;
to
return (flags | LOOK_NUL);
that's equal complexity, I would say. The benefit is saving
CPU cycles. For repositories with little binary content, like
fossil and sqlite, it would not make any noticable difference.
But in fossil repositories with much binary content it _could_
make a difference.
> That should be up to the calling code. The looks_like_utf*() should
> treat all flags with more-or-less equal priority.
Agreed, although an exception for LOOK_NUL would not harm. fossil
up to 1.25 worked fine, even though it treated LOOK_LENGTH and
LOOK_NUL special from other flags.
If the decision is made that the full blob content is
verified always, then I wonder what's the meaning of
the quoted line (subject of this mail), and the meaning
of the LOOK_SHORT flag:
#define LOOK_SHORT ((int)0x00000100) /* Unable to perform full check. */
Wouldn't this flags always be 0 then?
I'm not in the position to make this decision.
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
