History log of /fuchsia/zircon/system/ulib/fidl/message.cpp
Revision Date Author Comments
# 1c6b355c 03-Jul-2018 Adam Barth <abarth@google.com>

[fidl] Teach code that fidl_decode closes handles on error

We were closing handles twice in a few cases. It's hard to observe that
change because we ignore the return value of zx_handle_close in these
cases.

Test: No observable change in behavior
Change-Id: Iac3401fcee936d10540d86abf0e42935254de8cc


# 1e693af8 26-Jun-2018 Adam Barth <abarth@chromium.org>

[cleanup] Use zx_handle_close_many in several places

zx_handle_close_many is more readable than a loop.

Test: No behavior change.
Change-Id: I52e07f1006c955dcea39be508ce4053b6489b54a


# 53a24913 21-Jun-2018 Adam Barth <abarth@chromium.org>

[syscalls] Remove read_status from zx_channel_call

This parameter no longer has a purpose. Also, remove ZX_ERR_CALL_FAILED.
This status code no longer has a purpose.

Test: No behavior change
Change-Id: I71945ea9d1d6d591a20476106df1e598dfaf97b1


# 11b16c13 19-Jun-2018 Adam Barth <abarth@chromium.org>

[syscalls] zx_channel_call should always consume handles

Previously, whether zx_channel_call consumed handles depended on whether
it succeeded or failed.

ZX-2204 #comment

Test: utest/core/channel

Change-Id: Ic7b1149a85a1a892144479ee2f543fc7fedc6114


# fa20df6f 16-Jun-2018 Adam Barth <abarth@chromium.org>

[syscalls] zx_channel_write should always consume handles

Previously, whether zx_channel_write consumed handles depended on
whether it succeeded or failed.

ZX-2204 #comment

Test: utest/core/channel
Change-Id: Ie44a8e101fa5e7d0cefc1e1e65cfd084640aa54f


# 9452cd29 14-May-2018 Adam Barth <abarth@google.com>

[fdio] Implement fdio_spawn

This function packages up its arguments and calls the process launcher
service to launch the process.

Change-Id: I831ec962489153b08409898ffa9796d29bad7b40


# 51da239b 14-Mar-2018 James Robinson <jamesr@google.com>

[fidl] Move public fidl headers to match naming convention

The fidl library provides headers intended for general use, so the
include path should be spelled <lib/fidl/foo.h> as per
https://fuchsia.googlesource.com/docs/+/master/development/languages/c-cpp/naming.md.
This moves the headers into the proper location and updates includes to
match.

Change-Id: I9db162c3fd40170d63730bc9b7079c7e7e950982


# 51b05d56 03-Mar-2018 George Kulakowski <kulakowski@google.com>

[fidl] Validation doesn't need the handles, just a count

Change-Id: I85a9cc6bd6894cacb4277319bb19ce527c72b7d9


# d1e97107 27-Feb-2018 Adam Barth <abarth@google.com>

[fidl] Add fidl_validate

This function validates an encoded FIDL message without transforming it
to the decoded state.

Change-Id: I963806b4b4dd32f3fc461ae91ed2765542d866c9


# 3ff76223 11-Feb-2018 Sean Klein <smklein@google.com>

[fidl] Fix multiple fidl::Message::Call bugs

1) If the return status from zx_channel_call is ZX_OK,
then read_status will not be set. As a consequence, the
following code:

fidl::Message message(...);
zx_status_t read_status;
message.Call(..., &read_status, ...);

Will attempt to use an uninitialized value of read_status
from the stack. This patch prevents reading read_status
for this reseponse-setter logic.

2) If Message::Call is invoked as follows:

fidl::Message message(...);
message.Call(..., &message);

Then the call to "ClearHandlesUnsafe" will memset the
response handles to zero, even if they were valid, potentially
leaking them, before setting "response->handles_" to "actual_handles".

This is fixed by allowing "ClearHandlesUnsafe" to alter
the "actual" handle count without memsetting the handles field.

ZX-1698 #done

Change-Id: I23aac0eb87cc5dbc5f68ec79b444cb6ff18edef2


# d4a78c78 11-Feb-2018 Sean Klein <smklein@google.com>

[fidl] Prevent ZX_ERR_CALL_FAILED from causing double handle closes

ZX-1695 #done

Change-Id: I79e5b95e74ac87c422aba65e0bdb197273e0d064


# bdbed083 11-Feb-2018 Sean Klein <smklein@google.com>

[fidl] Fix the argument order to zx_channel_read

ZX-1694 #done

Change-Id: Ib68d66b92669b7ecb04b1953d5810e43de13b252


# 35980106 11-Feb-2018 Sean Klein <smklein@google.com>

[fidl] Allow clients of ulib/fidl to extract handles manually

ZX-1693 #done

Change-Id: Ib1fd37819bc97d19d5ca09069fb44e9513d5e2a0


# 27f70ff6 18-Jan-2018 Adam Barth <abarth@chromium.org>

[fidl] Add MessageBuilder, which owns the message memory

MessageBuilder is a utility class that makes it easy to build up
messages. Clients that wish to manage memory more precisely should use
Builder and Message separately.

Change-Id: Ia2f664a5d3404bcb224bf58d473dc2edbfef2edb


# 54d819b9 17-Jan-2018 Adam Barth <abarth@chromium.org>

[fidl] Add fidl::Message data structure

The fidl::Message data structure holds both the byte and the handle part
of a FIDL message and knows how to encode and decode messages in place.
The fidl::Message also knows about the message header and its various
fields.

This CL also moves the C++-related headers into a cpp directory to make
it easier to see which parts of the library are related to the C++
bindings and which are useful from C.

Change-Id: I7031d1b3d9a76b911f7e9de9c3f5aa33a0f700f8