Re: possible bug in tortoisemerge when diffing files containing NULLs

Stefan, I must respectfully disagree with your assessment. Strings are not
by definition null-terminated. In most modern programming languages, the
string datatype includes the length of the string explicitly, and thus can
store embedded nulls. In C++, the std::string class (and also the CString
class that comes with MFC) supports embedded nulls. The same is true of C#
strings, and I think also Java strings. Pretty much only C-style character
arrays suffer from the problem.

The SVN CLI binary will treat the files in question as text (occasionally it
requires --force to do so, such as with "svn diff", but "svn cat" does not
require it). It outputs the null character verbatim and requires the
terminal to display it appropriately. Usually the displaying is done as a
control character escape sequence of the form ^@, where the caret denotes
the control key and @ is the key you press with it to get the desired null
character. Support for reading files containing null characters is nearly
universal on *nix platforms, and the control characters are almost always
denoted in that way. Support on Windows is not as certain, but still quite
common: WinMerge, BeyondCompare, TextPad, Firefox, etc. TextPad displays
the character as a simple black box. WinMerge (and probably most other
unicode-aware apps) displays it as a box with the hex code inside it (in
this case, the hex code being 0000).Perhaps it would be possible to
implement one of these approaches in TortoiseMerge?

In my experience of converting other apps to support embedded nulls, the
changes necessary are very simple, since there are usually very few places
in the code where the strings are being treated as C-style arrays instead of
actual objects. Usually these places are around translating from one
representation to another at API boundaries. If I knew it was actually as
easy as the other times I've done this, I'd consider submitting a patch, but
just getting spun-up enough on the TortoiseMerge codebase to estimate the
level of effort would probably take me quite a while. There's also the
issue of my company not being willing to spare my time to do so...

Tortoise is a great product and I appreciate the work you've put into it. I
hope this enhancement request can make it onto the list of low-hanging fruit
for possible inclusion in a future release.

Thanks,
Ryan (aka Yanroy)

Stefan Küng wrote:
>
> Yanroy wrote:
>> I've noticed what I'm pretty sure is a bug in TortoiseMerge. If I diff a
>> text file that contains NULLs (0x00), the text is cut off at the first
>> NULL.
>> Somewhere inside TortoiseMerge, it must be using null-terminated strings.
>
> Strings are by definition terminated by a null-char.
>
>> It would be a great help to me if I could diff these files properly.
>> These
>> files are human-readable (i.e. non-binary) MS SQL Server import files,
>> which
>
> And how is the null char shown? Such files are not real text files,
> that's why TMerge doesn't treat them as such (it has no way to show a
> null char).
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2359170
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_tortoisesvn.tigris.org].
>
>

-- 
View this message in context: http://www.nabble.com/possible-bug-in-tortoisemerge-when-diffing-files-containing-NULLs-tp23839367p23857679.html
Sent from the tortoisesvn - users mailing list archive at Nabble.com.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2359203
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].