This changes the API of xfa from
XFA(array_name, prio) type element_name = INITIALIZER;
to
XFA(type, array_name, prio) element_name = INITIALIZER;
this allows forcing natural alignment of the type, fixing failing tests
on `native64`.
This disables adding/removing line breaks by `clang-format`, as this
could very well introduce regressions in code formatting in terms of
our coding convention: If a long array was matching the soft limit of 80
chars per line, `clang-format` would reflow it to match the hard limit
of 100 chars.
One can selectively disable `clang-format` with magic comments. But at
this point, I'd say we should rather disable this feature until we
can configure it in a way to match our coding convention better (without
having to add magic comments).
Before the test used the `help` command to verify that access to the
shell is present. While this does have the benefit of not requiring a
custom command, it does have some robustness issues:
- When new default commands get added, this test will fail
- When the help message of a command gets reworded, the test will fail
- When the order of commands in the test will change, the test will fail
- Note that with the XFA based `SHELL_COMMAND()` macro, we do not
guarantee any particular order. Specifically, the order can change
with implementation details.
This increases the test coverage for XFA:
- Multiple entries are added from a single file
- Priorities are assigned to enforce a given order
- The size of the `struct` to add is changed to no longer be a power of
2
- Allow specifying an alternative board filter for the bootloader TTY,
as this will present different vendor, model, and serial than RIOT's
USB implementation.
- Allow specifying the serial. This is useful when multiple CDC ACM
devices are present.
Before, handlers writing blockwise transfer assumed that the response
header length will match the request header length. This is true for
UDP, but not for TCP: The CoAP over TCP header contains a Len field,
that gets extended for larger messages. Since the reply often is indeed
larger than the request, this is indeed often the case for CoAP over
TCP.
Note: Right now, no CoAP over TCP implementation is upstream. However,
getting rid of incorrect assumptions now will make life easier
later on.
This increases test coverage for coap_build_reply_header() for the case
that extended tokens are used. The test validates the correctness of
the return value and the correctness of the assembled reply.
In case no payload is added, `coap_build_reply_header()` would return
`sizeof(coap_hdr_t) + token_length` regardless of the actual header
length returned by `coap_build_hdr()`. These can be different if
RFC 8974 extended tokens are enabled (module `nanocoap_token_ext`
used): If an extended token length field is used, its size is not
considered.
Co-authored-by: benpicco <benpicco@googlemail.com>
This makes an implicit agreement that code should include the headers
is uses, no more and no less, explicit.
It also recommends using tooling (such as clangd) and adding IWUY
pragma comments to aid those tools in common cases they otherwise would
provide false positives.
Co-authored-by: chrysn <chrysn@fsfe.org>
