chriskohlhoff / asio-tr2 Goto Github PK

Name TBD. Wording modelled on things like BinaryTypeTrait.

on the function const_buffers_1 buffer(basic_string_view<CharT, Traits> str, size_t n)

You've got two conflicting bits here:

Requires: a.is_v4_mapped()
and
Throws: bad_address_cast if a.is_v4_mapped() is false

"Requires" is a precondition - you can't call the function without satisfying the precondition.

Based on FS or Concurrency. Also need to reference Library fundamentals for string_view.

They can't be references, but actual values.

We wouldn't want people to implement it that way.

See https://threatpost.com/enterprise-apps-in-scope-of-ghost-glibc-vulnerability/110909 and http://threatpost.com/ghost-glibc-remote-code-execution-vulnerability-affects-all-linux-systems/110679 for more about why we don't want people using gethostbyname.

Throughout the document, string_view parameters are passed by const reference.

The string_view type is small, cheap to copy, and designed to be passed by value.

Also, there's a typo "string_vew" in the address_v6 section

The only thing that's there is the constructors. There are no accessors nor public member variables, so there's no (documented) way to get the data out of this class.

I.e. remove "in this clause" except where the requirement is not generally required, but just how the ones in this clause behave.

Need to specify under what conditions the return value of x.context() can change.

In the address_iteratorXX classes, you have

typedef const addressXX* pointer;
typedef const addressXX& reference;

but then you define functions thus:

const addressXX& operator*
const addressXX* operator->

The return types of these functions should be reference and pointer.

The constructors are constexpr. All the pieces needed to compare them are (at least for v4, they are; I'm not 100% sure about v6 and address).

JW to provide wording. For use in async.reqmts.async.alloc.

We will look at using SFINAE or similar at each place where it is used to branch code.

Avoid duplication if possible

x1 is const X, but we need a non const variable. Rename variables to x1, x2, cx1, cx2.

There are four overloads of read() defined in section 10.8.19.

read(stream, buffers);
read(stream, buffers, error);
read(stream, buffers, completion);
read(stream, buffers, completion, error);

• What is the difference in behavior between the versions that take an error_code and the ones that do not? [ My guess is that when the error code is non-zero, they throw it, but the spec doesn't say that ]
• If that is true, should the versions that take an error code be noexcept?

The same questions apply to write()

Clock
Allocator
ExecutionContext

Extends 17.5.1.4 from main standard.

Also impact on shutdown_context etc.

Make these changes from executor for allocators:

A completion handler object of type Handler has an associated executor object
ex2 of type Executor2 satisfying the [link requirements.executor Executor
requirements]. The type Executor2 is associated_executor_t<Handler, Executor1>. The object ex2 is obtained by performing
associated_executor<Handler, Executor1>::get(handler, ex1).

I.e. it should be suppressed.

The proposal currently specifies that a default constructed ip::address have is_ipv4() == false and is_ipv6() == false. Or to put it another way, the ip::address class can contain:

• an IPv4 address; or
• an IPv6 address; or
• a Not-An-Address value

So right now the ip::address class can represent a value that is outside the domain of valid IP addresses. This is not the established practice in Asio and as I implement this I am finding that it might cause inconsistencies in the other types that use ip::address, like ip::basic_endpoint.

In the standard, when we define a full set of comparison operators, we usually define them all in terms of < and ==. If you look at the relational operators for in N4336, you’ll see what I mean.

Note that this is already the case for address_v6

Input iterators have weird semantics - there can be only one on a sequence at once, for example.
You can't back up, and yet you've got operator -- on them.

Why not (at least) bidirectional iterators?

Just use std::experimental::

Also shutdown_service on execution_context::service

Also add to table at front of document.

handler_type_t etc

In the standard, every section has a unique name such as [container.requirements]. (and the section names are hierarchical)

Sometimes sections get renumbered, but the name acts as a “unique identifier” for the section.
More practically, the LWG issue tools use the section names to group issues, and the libc++ test suite is organized according to section name.

So, "10.13.4. Class ip::address” could have a name of [ip.address]
followed by [ip.address.address_v6] and [ip.address.address_v4]

I think this will make the review go easier (and make tracking changes across revisions simpler, too)

Need to talk about how the zero-argument function object is constructed based on the asynchronous operation's completion signature. Add cross reference to completion signature.

Decorator, etc.

Use default parameters.

I.e. Executor1, ex1, etc etc.

E.g.:

This section uses the names Executor 1, ex1, ... as placeholders for specifying the requirements below.

As was done for wrap()

Given:
make_address_v4(unsigned long);
make_address_v4(const char *);

The call: make_address_v4(0) is ambiguous (or so says clang)

E.g. describe phases of an operation. Phase 1 - operation is pending. Phase 2 callback is submitted for execution.

It's just got a constructor - that's all.

One should be a negation of the other. Do in terms of the final overload's Remarks.