freeaddrinfo(3) only defined to free one or more addrinfo structures
returned by getaddrinfo(3). Thus, it's undefined behaviour for calling
freeaddrinfo(3) on nullptr, some libc only call free(3) on the the
passed addrinfo, but other libc assumes the addrinfo is always valid.
Let's be explicit instead of relying on undefined behaviours.
Let's drop one call to freeaddrinfo(3) because the addrinfo there is
always nullptr and guard the second.
This commit updates `ContentReader::read` to optionally close the
underlying `Reader` when a message is read that does not terminate
the DAP header immediately following the `Content-Length` header
field.
This fixes an infinite loop when parsing an invalid DAP message. In
particular, the infinite loop occurs when a cross-site HTTP request from
a browser running on the same host as a cppdap server is sent to the
server. As cross-site requests to the localhost can be triggered by
untrusted JavaScript, more validation of the DAP messages is required to
protect cppdap-based servers from malicious requests.
This commit introduces a new enum flag on both `Session` and
`ContentReader` to allow a user to indicate that the underlying `Reader`
should be closed when an invalid DAP message is received. The
server example has been updated to indicate that invalid messages
should result in closure of the underlying `Reader`.
Per #115, `ContentReader::match` must block until the whole pattern is
read or the underlying `Reader` is closed. The previous commit reverted
the change from #50 to ensure this behavior is still implemented.
This commit re-adds the unit test from #50 with an update to the
behavior of `StringBuffer` to correct implement `Reader` so that
the partial read test case is still covered by the unit tests.
A callback function to signal that the endpoint has closed its connection.
Add this as an optional argument to Session::bind() and Session::startProcessingMessages().
Bug: #98
* CMake: Fix target options
* update CMake package version after protocol sync
* Update protocol to 1.59.0
* protocol_gen: change OneOf to `object` type
The DAP spec introduces ambiguities with its particular uses of OneOf,
which means that we can't deserialize the variants generated from it.
Just set OneOf to an `object` type, like godap does.
This was entirely broken:
* The `Server` `Impl` used a `do{}while(false)` block, which never attempted to accept another connection after the first connection closed (#69)
* The `Server` `Impl` could deadlock with the mutex being locked by both the thread calling `isRunning()` and `stopWithLock()` waiting on `thread.join()`.
* `Socket::accept()` didn't check that the returned socket was valid, and could return a `ReaderWriter` that would just error on IO.
* `Socket::accept()` could deadlock on macOS as `shutdown()` can seemingly fail to unblock an accept call. This has been worked around by calling `close()` outside of the mutex write-lock. This introduces a potential race, but I'm not sure of a better solution right now.
Fixes: #69
Schema top-level definitions, such as `InvalidatedAreas` and `SteppingGranularity` were being emitted as empty structures, when they were actually enumerators.
Re-work protocol_gen.go to emit these correctly.
Also bumps the protocol to DAP version 1.46.0
When there is partial message in reader, popping out the
characters lead to parse errors on the subsequent attempt
to parse. To avoid this, the last matched characters'
index is stored during parsing and reset on error.
Bind API is split into connect and startProcessingMessages calls.
This enables users to directly call connect and manage processing
messages on user threads.
bindNoThread in conjunction with OnDataAvailable will provide
users with a choice of thread to process requests on. This is
useful when the user relies on single threaded message loop based
design to avoid locking.
Define `JSON_NOEXCEPTION` to avoid raising exceptions.
Exceptions are usually disabled for Google projects (https://google.github.io/styleguide/cppguide.html#Exceptions).
Also pass `false` to the `allow_exceptions` parameter of `nlohmann::json::parse()`.
Issue identified by @kuafuwang in #26.
`DAP_IMPLEMENT_STRUCT_TYPEINFO_EXT` and `DAP_STRUCT_TYPEINFO_EXT` are two new flavors of `DAP_IMPLEMENT_STRUCT_TYPEINFO` and `DAP_STRUCT_TYPEINFO` that allow you to derive message types.
This involved a bit of reworking on the serializer interfaces.
Added test.
Issue: #32
DAP usually consists of small packet requests, with small packet responses. When there are many frequent, blocking requests made, Nagle's algorithm can dramatically limit the request->response rates.
