Kokoro changes:
- Linux: gcc-13, cmake-3.31.2
- Windows: python 3.12, cmake-3.31.2
* Disable warnings in gtest, gmock
This is required in order to build with GCC 13, and Apple Clang with warnings-as-errors
Bug: crbug.com/383538610
* disable license check on .github/workflows/main.yml
* Use add_subdirectory for internal gtest, gmock
---------
Co-authored-by: Antonio Maiorano <amaiorano@google.com>
On `gcc-15` without the include header can't be used as is. I noticed
`cmake` build failing as:
dap/network.h:31:39: error: 'uint32_t' has not been declared
31 | uint32_t timeoutMillis = 0);
| ^~~~~~~~
The change adds `uint32_t` declaration via `<stdint.h>`.
The argument in the corresponding if() was changed in
commit ae76a38. CMake emits a warning.
Modern CMake style guides advice on ommitting endif()
arguments.
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.
The `CPPDAP_JSON_{NLOHMANN,RAPID}` compile definition is used only in
cppdap's implementation sources, and does not need to be defined by
dependents including our headers.
Also avoid exposing `nlohmann_json::nlohmann_json` as a public link
dependency of our installed package. It is used only when compiling
cppdap.
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.
Add options to link against external JSON libraries
This adds two options to the CMake config:
`CPPDAP_USE_EXTERNAL_NLOHMANN_JSON_PACKAGE` and `CPPDAP_USE_EXTERNAL_RAPIDJSON_PACKAGE`
If either of these is set, instead of using the json submodule, the build will be configured by using `find_package()` and linking against the specified JSON library.
In C++11, shared_ptr has an explicit operator bool which
means that a shared_ptr can't be implicitly converted to a bool.
adding an explicit cast is a valid fix to the code.
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
