{"id":110297,"date":"2024-09-23T07:00:00","date_gmt":"2024-09-23T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110297"},"modified":"2024-09-23T09:10:24","modified_gmt":"2024-09-23T16:10:24","slug":"20240923-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240923-00\/?p=110297","title":{"rendered":"Going beyond the empty set: Embracing the power of other empty things"},"content":{"rendered":"

The empty set contains nothing. This sounds really silly, but it’s actually really nice.<\/p>\n

The Windows Runtime has a policy that if a method returns a collection (such as an IVector<\/code>), and the method produces no results, then it should return an empty collection, rather than a null reference<\/a>. That way, consumers can just iterate over the collection without having to deal with a null test.<\/p>\n

For example, suppose you have a method Widget::Get\u00adAssociated\u00adDoodads<\/code> which returns an IVectorView<Doodad><\/code> representing the Doodad<\/code> objects that have been associated with a Widget<\/code> object. If no Doodad<\/code>s have been associated with the Widget<\/code>, then it should return an empty vector, not a null pointer. That allows developers to write the natural-looking code:<\/p>\n

\/\/ C#\r\nforeach (var doodad in widget.GetAssociatedDoodads()) {\r\n    \u27e6 process each doodad \u27e7\r\n}\r\n\r\n\/\/ C++\/WinRT\r\nfor (auto&& doodad : widget.GetAssociatedDoodads()) {\r\n    \u27e6 process each doodad \u27e7\r\n}\r\n\r\n\/\/ JavaScript\r\nwidget.GetAssociatedDoodads().forEach(doodad =>\r\n{\r\n    \u27e6 process each doodad \u27e7\r\n});\r\n<\/pre>\n
rather than having to insert a null test (which is easily forgotten):<\/p>\n
\/\/ C#\r\nvar doodads = widget.GetAssociatedDoodads();\r\nif (doodads != null) { \/\/ annoying null test\r\n    foreach (var doodad in widget.GetAssociatedDoodads()) {\r\n        \u27e6 process each doodad \u27e7\r\n    }\r\n}\r\n\r\n\/\/ C++\/WinRT\r\nauto doodads = widget.GetAssociatedDoodads();\r\nif (doodads) { \/\/ annoying null test\r\n    for (auto&& doodad : doodads) {\r\n        \u27e6 process each doodad \u27e7\r\n    }\r\n}\r\n\r\n\/\/ JavaScript\r\nvar doodads = widget.GetAssociatedDoodads();\r\nif (doodads) { \/\/ annoying null test\r\n    doodads.forEach(doodad =>\r\n    {\r\n        \u27e6 process each doodad \u27e7\r\n    });\r\n}\r\n<\/pre>\n
The principle of the empty collection applies to other types of collections, like IMap<K, V><\/code>, array<\/code>. You can think of strings as collections of characters, and you can think of memory buffers (such as IBuffer<\/code>) as collections of bytes.<\/p>\n
An example of a poor design is the Cryptographic\u00adBuffer<\/code> class. (Sorry, Cryptographic\u00adBuffer<\/code>, for throwing you under the bus.)<\/p>\n\n\n\n\n\n\n\n\n
Method<\/th>\nExpected Result<\/th>\nActual Result<\/th>\n<\/tr>\n
buffer = ConvertStringToBinary(\"\");<\/code><\/td>\nbuffer != null<\/code>
\nbuffer.Length == 0<\/code><\/td>\n		buffer == null<\/code>
\nbuffer.Length \/* crashes *\/<\/code><\/td>\n<\/tr>\n
buffer = CreateFromByteArray(new[] {});<\/code><\/td>\n<\/tr>\n
buffer = DecodeFromBase64String(\"\");<\/code><\/td>\n<\/tr>\n
buffer = DecodeFromHexString(\"\");<\/code><\/td>\n<\/tr>\n
buffer = GenerateRandom(0);<\/code><\/td>\nbuffer != null<\/code>
\nbuffer.Length == 0<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If the Convert\u00adString\u00adTo\u00adBinary<\/code>, Create\u00adFrom\u00adByte\u00adArray<\/code>, Decode\u00adFrom\u00adBase64\u00adString<\/code>, Decode\u00adFrom\u00adHex\u00adString<\/code> are given empty strings or arrays, you expect them to produce an empty buffer, but instead they return no buffer at all<\/i>.<\/p>\n
This means that code like this looks correct:<\/p>\n
\/\/ Write the string to a file as UTF-8\r\nvar buffer = CryptographicBuffer.ConvertStringToBinary(\r\n        BinaryStringEncoding.Utf8, message);\r\nawait FileIO.WriteBufferAsync(storageFile, buffer);\r\n<\/pre>\n
but then you discover (probably at a very inconvenient moment) that it crashes if the message is an empty string, because Convert\u00adString\u00adTo\u00adBinary<\/code> returned null<\/code> (instead of a non-null reference to an empty buffer), and then Write\u00adBuffer\u00adAsync<\/code> threw an invalid parameter exception because the buffer cannot be null.<\/p>\n
On the other hand, if you ask Generate\u00adRandom<\/code> to generate zero random bytes, it correctly gives you an empty buffer, rather than a null pointer. So at least one of the methods in the CryptographicBuffer<\/code> class understands how empty collections work.<\/p>\n
As a bonus insult, the Cryptographic\u00adBuffer.Compare<\/code> method requires that both buffers be non-null, so you can’t even do this:<\/p>\n
\/\/ Do it twice and confirm the results are the same\r\nvar buffer1 = CryptographicBuffer.ConvertStringToBinary(\r\n        BinaryStringEncoding.Utf8, message);\r\nvar buffer2 = CryptographicBuffer.ConvertStringToBinary(\r\n        BinaryStringEncoding.Utf8, message);\r\nif (CryptographicBuffer.Compare(buffer1, buffer2)) {\r\n    \/\/ the buffers are equal\r\n}\r\n<\/pre>\n
The code crashes if the message is an empty string because buffer1<\/code> and buffer2<\/code> will be null<\/code>, which is not a valid parameter to Cryptographic\u00adBuffer.Compare<\/code>. It’s a bit ironic that the Cryptographic\u00adBuffer<\/code> can dish out null buffers but can’t take them.<\/p>\n
Cryptography in general seems to have a hard time with the concept of zero. The User\u00adData\u00adProtection\u00adManager.Protect\u00adBuffer\u00adAsync<\/code> method, for example, rejects attempts to protect an empty buffer, so if you want to protect a buffer that might be empty, you need to special-case the empty buffer.<\/p>\n
\/\/ This version crashes if the buffer is empty.\r\nstatic class Protector\r\n{\r\n    static UserDataProtectionManager manager =\r\n        UserDataProtectionManager.TryGetDefault();\r\n\r\n    public Task<IBuffer> ProtectBufferAsync(IBuffer buffer)\r\n    {\r\n        if (manager != null) {\r\n            return await manager.ProtectBufferAsync(buffer,\r\n                    UserDataAvailability.AfterFirstUnlock);\r\n        } else {\r\n            \/\/ No protection available - leave unprotected.\r\n            return buffer;\r\n        }\r\n    }\r\n\r\n    public Task<IBuffer> UnprotectBufferAsync(IBuffer buffer)\r\n    {\r\n        if (manager != null) {\r\n            return await manager.UnProtectBufferAsync(buffer);\r\n        } else {\r\n            \/\/ No protection available - it was left unprotected.\r\n            return buffer;\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
A na\u00efve way of fixing this is to detect an empty buffer and just skip the Protect\u00adBuffer\u00adAsync<\/code> call, letting an empty buffer be its own protected buffer. This is a bad idea, however, because a bad guy who sees an empty protected buffer will know that this represents an empty unprotected buffer. If the buffer represents a password, then they will know that the password is blank!<\/p>\n
If you choose some sentinel non-empty buffer value to represent a non-empty buffer, you then have to have some way of distinguishing this from a genuine non-empty buffer that happens to match your sentinel. In mathematical terms, your function that converts buffers to non-empty buffers needs to be injective. One way is to append a dummy byte to the buffer, and remove the dummy byte when unprotecting.<\/p>\n
\/\/ C#\r\n\r\n\/\/ Work around inability to protect empty buffers\r\n\/\/ by appending a dummy byte to all buffers.\r\nvar paddedBuffer = WindowsRuntimeBuffer.Create(buffer.Length + 1);\r\npaddedBuffer.Length = actualBuffer.Capacity;\r\nbuffer.CopyTo(paddedBuffer);\r\nvar protectedBuffer = await manager.ProtectBufferAsync(\r\n    paddedBuffer, UserDataAvailability.AfterFirstUnlock);\r\n\r\n\/\/ Reverse the workaround by removing the dummy byte\r\n\/\/ after unprotecting.\r\nvar result = await manager.UnprotectBufferAsync(protectedBuffer);\r\nif (result.Status == UserDataBufferUnprotectStatus.Succeeded)\r\n{\r\n    var trimmedBuffer = result.UnprotectedBuffer;\r\n    trimmedBuffer.Length = trimmedBuffer.Length - 1;\r\n    \u27e6 do something with the trimmed buffer \u27e7\r\n}\r\n\r\n\/\/ C++\r\n\r\n\/\/ Work around inability to protect empty buffers\r\n\/\/ by appending a dummy byte to all buffers.\r\nauto length = buffer.Length();\r\nauto paddedBuffer = winrt::Buffer(length + 1);\r\npaddedBuffer.Length(length + 1);\r\nmemcpy_s(paddedBuffer.data(), length, buffer.data(), length);\r\nauto protectedBuffer = co_await manager.ProtectBufferAsync(\r\n    paddedBuffer, winrt::UserDataAvailability::.AfterFirstUnlock);\r\n\r\n\/\/ Reverse the workaround by removing the dummy byte\r\n\/\/ after unprotecting.\r\nauto result = co_await manager.UnprotectBufferAsync(protectedBuffer);\r\nif (result.Status() == winrt::UserDataBufferUnprotectStatus::Succeeded) {\r\n    auto trimmedBuffer = result.UnprotectedBuffer();\r\n    trimmedBuffer.Length(trimmedBuffer.Length() - 1);\r\n    \u27e6 do something with the trimmed buffer \u27e7\r\n}\r\n<\/pre>\n
The inability to handle zero-byte buffers makes everybody’s life harder.<\/p>\n
Zero. It’s a valid number. Please support it.<\/p>\n","protected":false},"excerpt":{"rendered":"
Just because there’s nothing in it doesn’t mean it’s not valid.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-110297","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Just because there’s nothing in it doesn’t mean it’s not valid.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110297","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=110297"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110297\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=110297"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110297"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110297"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}