.NET String Immutability and Related .NET Framework Bugs

Console.WriteLine(path);
Console.WriteLine(originalPath);

The code produces output like this:

C:\Win...\system32
C:\Win...\system32

We have changed only the first string. But both string objects contain the modified value. The workaround for this problem is simple. Instead of the line:

string originalPath = path;

Write this:

string originalPath = string.Copy(path);

That will force a new buffer to be created, so the path and originalPath objects will not share the internal buffer any more. The result is as expected:

C:\Win...\system32
C:\Windows\system32

I hope that at least the String.Copy method documentation would mention buffer sharing, but it does not.

Bug #2

The latest output may be looking very good but it is not good. If we change the printout code then the difference will emerge:

Console.WriteLine("{0} chars - [{1}]", path.Length, path);
Console.WriteLine("{0} chars - [{1}]", originalPath.Length, originalPath);

This code prints different output:

19 chars - [C:\Win...\system32 ]
19 chars - [C:\Windows\system32]

Now observe the output; both strings declaratively have the same length!

The problem is that the MeasureText method has made another mistake, related to the previous one. It did not modify the string length. But that is not all; the PathCompactPathEx Windows API has placed a C-style string terminating character '\0' at the end of the compacted path. But this character is not considered a terminator in .NET. In most occasions it is treated as a regular character (it is ignored in culture-based string comparison, but treated as a regular character in normal string comparisons). The problem becomes obvious if we pick a longer path to compact (application data for instance). The output looks like this:

31 chars - [C:\User...\Roaming Data\Roaming]
31 chars - [C:\Users\zoranh\AppData\Roaming]

As you can see, the string was compacted, the middle part was replaced by an ellipsis, but after the end, there is a blank space ('\0' character) and then the remainder of the original string. All is the consequence of leaving the original string length unchanged instead of modifying it so that the string ends at the C string terminator character.

This bug has been reported to Microsoft, and it is currently in the status Won't fix, which means that Microsoft has higher priorities. The bug is reported at this address: http://connect.microsoft.com/VisualStudio/feedback/details/620330/textrenderer-measuretext-with-textformatflags-pathellipsis-textformatflags-modifystring-flags#details.

The bug is of no priority to Microsoft because there is a simple workaround. After adding an ellipsis to the string, we should manually search for the '\0' character and cut the string at that position:

int pos = path.IndexOf('\0');
if (pos >= 0)
path = path.Substring(0, pos);

The output now looks like new:

18 chars - [C:\User...\Roaming]
31 chars - [C:\Users\zoranh\AppData\Roaming]

Bug #3

Suppose that we decide to use System.IO.DirectoryInfo to reference the application data directory; quite a common requirement. We can keep the string with an ellipsis for the purpose of printing out a directory path of limited length, and maintain the DirectoryInfo object pointing to the directory. The code looks like this:

string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
System.IO.DirectoryInfo dir = new System.IO.DirectoryInfo(path);

System.Drawing.Font font = new System.Drawing.Font(System.Drawing.FontFamily.GenericSansSerif, 8.25F);
System.Drawing.Size proposedSize = new System.Drawing.Size(100, 100);
System.Windows.Forms.TextFormatFlags flags = System.Windows.Forms.TextFormatFlags.ModifyString | System.Windows.Forms.TextFormatFlags.PathEllipsis;
System.Windows.Forms.TextRenderer.MeasureText(path, font, proposedSize, flags);

int pos = path.IndexOf('\0');
if (pos >= 0)
path = path.Substring(0, pos);

try
{

Console.WriteLine("{0} chars - [{1}]", path.Length, path);
Console.WriteLine("Directory path: {0}", dir.FullName);

}
catch (System.Exception ex)
{
Console.WriteLine("ERROR: {0}", ex.Message);
}

The output looks like this:

18 chars - [C:\User...\Roaming]
Directory path: C:\Users\zoranh\AppData\Roaming

Notice the try-catch block around the printout statements. This is added for a purpose. Starting with .NET Framework 4.0, the DirectoryInfo's FullPath property shares the same buffer with the path string! So if we run the same code in .NET Framework 4.0, the output is transformed into this:

18 chars - [C:\User...\Roaming]
ERROR: Illegal characters in path.

The Exception is caused by the '\0' character that was inserted into the FullPath's buffer when the path was changed by the MeasureText method. This character is not legal when used in a file system path and hence the exception is thrown.

The problem occurs only when a DirectoryInfo object is initialized with an absolute path. If a relative path is used then DirectoryInfo cannot share the buffer with the initialization string, because it requires a full path to the directory. The reason is simple: a relative path becomes invalid if the current directory is changed.

Here is the code that uses a relative path to initialize the DirectoryInfo object. There is no exception even in the .NET Framework 4.0.

string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

System.IO.DirectoryInfo dir = new System.IO.DirectoryInfo(path);
string root = dir.Root.FullName;

System.IO.Directory.SetCurrentDirectory(root);
path = path.Substring(root.Length);
dir = new System.IO.DirectoryInfo(path);

Console.WriteLine("Current directory: {0}", System.IO.Directory.GetCurrentDirectory());
Console.WriteLine("Relative path: {0}", path);
Console.WriteLine("Absolute path: {0}", dir.FullName);

System.Drawing.Font font = new System.Drawing.Font(System.Drawing.FontFamily.GenericSansSerif, 8.25F);
System.Drawing.Size proposedSize = new System.Drawing.Size(100, 100);
System.Windows.Forms.TextFormatFlags flags = System.Windows.Forms.TextFormatFlags.ModifyString | System.Windows.Forms.TextFormatFlags.PathEllipsis;
System.Windows.Forms.TextRenderer.MeasureText(path, font, proposedSize, flags);

int pos = path.IndexOf('\0');
if (pos >= 0)
path = path.Substring(0, pos);

try
{

Console.WriteLine("{0} chars - [{1}]", path.Length, path);
Console.WriteLine("Directory path: {0}", dir.FullName);

}
catch (System.Exception ex)
{
Console.WriteLine("ERROR: {0}", ex.Message);
}

The output looks like this:

Current directory: C:\
Relative path: Users\zoranh\AppData\Roaming
Absolute path: C:\Users\zoranh\AppData\Roaming
18 chars - [Users\z...\Roaming]
Directory path: C:\Users\zoranh\AppData\Roaming

We can see that DirectoryInfo has converted the relative path to an absolute path, that is further not affected by the MeasureText method because it doesn't share the character buffer with the path string object.

The workaround when DirectoryInfo is initialized in the general case (that may include an absolute path) is again to force a copy of the character buffer as in the following:

System.IO.DirectoryInfo dir = new System.IO.DirectoryInfo(string.Copy(path));

This way the DirectoryInfo object maintains its own internal character buffer regardless of the path object.

Conclusion

This article has demonstrated how the .NET Framework optimizes memory use in strings where possible. Optimization is based on the idea that a dummy copy of strings doesn't change the contents and length of the internal character buffer, which means that a copied object can point to the same internal buffer without loss of information.

We have further shown that the MeasureText function breaks the rule that a character buffer in string objects is read-only and allows the Windows API to write to it. Not only does the contents of the buffer become invalid, but also the supporting members of the string object become incorrect, like the one specifying the length of the string. We have pointed to three real-life situations in which these problems are fully manifested when working with file system object paths. Adding an ellipsis to paths is a common operation, and here we have shown that it is not possible to rely just on the .NET Framework's help to do that, but apropriate workarounds must be employed to avoid the effects of these bugs.

Some people prefer writing their own functions to compact paths. I find that way wrong, because unless the path is printed using monospaced fonts, you cannot determine how many characters, and which ones, should be dropped to satisfy the space limitations without measuring parts of the string. The MeasureText method from the .NET Framework is the way to do it. Never forget that it is coded to operate with the underlying GDI and platform. Changes in external libraries may cause your custom code which measures text to fail in the future, while MeasureText would be expected to reflect the changes and continue working correctly. The Bug in string manipulation, especially correctable ones, is not sufficient motive to give up and try managing things in a custom manner.