commit 2d77175087f2ad624e9d4d21e9e3b5a12ba43a65
author Yifei Teng <yifeit@google.com> Mon Jun 17 22:26:09 2019 +0000
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Mon Jun 17 22:26:09 2019 +0000
tree 62168dbd994489f7cfc080920429335bce63fff0
parent f921656ba3c0a64934b9df04bb37152ea960a189

[fidl] Convert non-nullable absent vectors/strings to empty when
linearizing

The decoded form of a present but empty vector/string has been:
count set to zero; data pointer set to the next out-of-line location.
This is difficult to construct by hand.

In the C bindings, people have been using "data=nullptr, count=0" to
denote an empty vector. The C bindings translate this to the valid
decoded form i.e. "data=next-out-of-line, count=0".

For LLCPP, we would like to support sending empty vectors, while
avoiding to manually construct the "next-out-of-line" data pointer.
There are a few approaches:

1. Amend the decoded form to use a magic address/special object location
as the data pointer of a present and empty vector. For example, we could
define the decoded form of an empty vector to be
"data=0xAAAAAAAA, count=0", and modify the fidl::VectorView class to
implement this behavior. We could add a VectorView::Empty() factory
method to create vectors of this form.

Pro: Consistent handling in the walker. Using an invalid address clearly
signals that the data pointer should not be dereferenced when the count
is zero.
Con: fidl::VectorView has setter functions for data and count. Setting
count to zero would have an "action at a distance" where unexpectedly the
data pointer is reset to this special address. Overall it had been
difficult to maintain an intuitive API while ensuring the
empty-means-special-address invariant.

2. Use the FIDL linearizer to translate absent vectors to empty vectors
when the corresponding field is non-nullable.

Pro: fidl::VectorView remains a "pure data class" with no surprising
behaviors.
Con: When the field is nullable, sending "data=nullptr, count=0" would
mean an absent vector. When the field is non-nullable, sending the same
would result in an empty vector. The same object content has differing
semantics.

After weighing the approaches, I think #2 results in the least amount of
surprises in the long run.

FIDL-682 #done

Change-Id: Ic6e38173bf3b185701c44758afdaee02e161afaf