### Motivation:
Additional partial platform support.
### Modifications:
* Create a new CNIOBSD module for OpenBSD, for general cleanliness, and
make use of it throughout. Some of the changes are borrowed directly
from CNIOLinux; some may technically be unnecessary; I am erring
somewhat on expediency to functionality.
* Since `malloc_size` is unavailable on OpenBSD, and some of the helpers
make use of ManagedBufferPointer which makes use of it, mark some of
this as unavailable as well.
* Usual pthread optional typing changes, since pthread types are
pointers on this platform.
* Add conditionals to exclude other functionality not available here,
like IP_RECVPKTINFO or IP_PKTINFO.
* d_ino is a backwards-compatibility macro valued token for dirent, so
instead, just expand with a conditional.
* Use kqueue on OpenBSD. This necessitates adding some conditionals for
type and feature compatibility.
* The vsock API is unavailable on OpenBSD.
### Result:
Tested the NIOTCPEchoClient and NIOTCPEchoServer appears to work and
that swift-nio-ssh (hopefully wlog) builds with a local repository with
these changes.
Because NIOFS/_NIOFileSystem depend on some non-portable components,
such as extended attributes, sendfile, non-portable linkat flags, and
renameat2, this is only just partial OpenBSD support, which means that
`swift build` on the full swift-nio project won't build cleanly, but at
least the portable parts can be used to build servers and clients. This
commit will mark the linked bug as fixed; I will open a new bug for file
system support.
Fixes#3383.
---------
Co-authored-by: Rick Newton-Rogers <rnro@apple.com>
TIL there is an `endian.h` on Linux and macOS that is imported through
`<sys/types.h>` on Linux and Apple platforms. Apparently such a header
file does not exist in Windows land. For this reason we need to define
the macros that we need here ourselves.
Dispatch is not supported on WASI, and only Unix domain sockets are
supported, which means we have to exclude those APIs on this platform.
There's work in progress to enable tests for this on CI, but nothing I
can provide for this PR at the current moment.
---------
Co-authored-by: Franz Busch <f.busch@apple.com>
# Motivation
We have quite a lot of shell scripts in our repo and want to make sure that they all pass `shellcheck`.
# Modification
This PR adds a GH action workflow to the soundness script for `shellcheck` and fixes up all errors and warnings.
# Result
No more shell/bash discussions
* [GHA] Unacceptable language check
# Motivation
Next up replacing part of our soundness script that checked for unacceptable language.
# Modification
This PR adds a new GH action that checks for unacceptable language.
# Result
One more script replaced
* PR review
* Change homepage link to repo
When building swift-nio with a system with explicit modules (bazel build rules) I was getting incorrect sha1 results. It turns out the root cause is the `BYTE_ORDER` macro was not defined in my build context.
Using `-Wundef` in clang I was seeing:
```
Sources/CNIOSHA1/c_nio_sha1.c:56:7: error: '__linux__' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:63:5: error: 'BYTE_ORDER' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:63:19: error: 'BIG_ENDIAN' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:113:5: error: 'BYTE_ORDER' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:113:19: error: 'LITTLE_ENDIAN' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:222:5: error: 'BYTE_ORDER' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:222:19: error: 'BIG_ENDIAN' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:267:5: error: 'BYTE_ORDER' is not defined, evaluates to 0 [-Werror,-Wundef]
^
Sources/CNIOSHA1/c_nio_sha1.c:267:19: error: 'BIG_ENDIAN' is not defined, evaluates to 0 [-Werror,-Wundef]
```
The soundness check was not actually signaling an error because it was implicitly comparing 0 to 0.
This change includes an update to the `#include`'s to ensure `BIG_ENDIAN` is defined on macOS and updates the soundness check to have an explicit error if `BYTE_ORDER` is not defined.
Co-authored-by: Cory Benfield <lukasa@apple.com>
Replace the non-portable `u_*_t` types with the C standard `u*_t` types
instead. Remove the Unix headers as the only headers really needed are
the C standard headers. Provide shims for deprecated `strings.h`
functions in terms of "modern" (C89+) functions from `string.h`. Move
an android only include into the implementation from the interface.
This enables building this library on Windows.
Co-Authored-By: George Barnett <gbrntt@gmail.com>
Co-authored-by: Johannes Weiss <johannesweiss@apple.com>
Motivation:
SwiftPM only generates fully usable clang modules for C modules if they
have umbrella headers. Therefore, adding a generated NIO.xcodeproj to
another Xcode project as a sub-project never worked.
To make a header an umbrella header you need to name them _exactly_ like
the module.
Modifications:
give each C module an umbrella header
Result:
generated NIO Xcode projects can be used as sub-projects.
### Motivation:
make swift-nio compatible with Android, and pass all test in Android.
### Modifications:
* add missed `ifaddrs` implementation
* add missed thread related functions - `CNIOLinux_pthread_getname_np`, `CNIOLinux_pthread_setaffinity_np` and `CNIOLinux_pthread_getaffinity_np`
* fix types incositency between Linux and Android, e.g. `Epoll.swift` class
* make bytes counter explicitely 64bits to avoid overflow on 32bit, in `PendingWritesManager.swift` and `PendingDatagramWritesState.swift`
* fix issue with Unix domain socket, first byte need to be zero in Android
* several incosistency fixes between Linux and Android api.
### Result:
now swift-nio works on Android. All tests passed!
Motivation:
Websockets is a major protocol in use on the web today, and is
particularly valuable in applications that use asynchronous I/O
as it allows servers to keep connections open for long periods of
time for fully-duplex communication.
Users of NIO should be able to build websocket clients and servers
without too much difficulty.
Modifications:
Provided a WebsocketFrameEncoder and Decoder that can serialize and
deserialize Websocket frames.
Result:
Easier use of websockets.