We do not need to add an array of pointers to the shell commands, just
an array of shell commands is sufficient. This reduced the overhead of
XFA by `sizeof(void *)` per command.
It's very unlikely that a pkt snip will have more than 255 users.
Use a uint8_t here to save 4 bytes per snip as this now fits into
the ununsed struct padding.
gnrc_tcp_open() previously would eventually fail with a timeout without
sending any data when no netif was specified and a link-local target
address was used. This fixes the behavior:
- If there is only one netif, we just pick that
- If there are multiple netifs, fail directly with `-EINVAL` rather than
sending out nothing and waiting for a timeout.
Co-authored-by: benpicco <benpicco@googlemail.com>
This command does the same as `help`, but provides a machine readable
JSON rather than a human readable table. It is only provided when the
(pseudo-)module `shell_builtin_cmd_help_json` is used.
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`.
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.
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>
gcoap contains a hack where a `coap_pkt_t` is pulled out of thin air,
parts of the members are left uninitialized and a function is called on
that mostly uninitialized data while crossing fingers hard that the
result will be correct. (With the current implementation of the used
function this hack does actually work.)
Estimated level of insanity: 😱😱😱😱😱
This adds to insane functions to get the length of a token and the
length of a header of a CoAP packet while crossing fingers hard that
the packet is valid and that the functions do not overread.
Estimated level of insanity: 😱😱😱
The newly introduced insane functions are used to replace the old
insane hack, resulting in an estimated reduction of insanity of 😱😱.
Side note: This actually does fix a bug, as the old code did not take
into account the length of the extended TKL field in case of
RFC 8974 being used. But that is a bug in the abused API,
and not in the caller abusing the API.
