Add small stubs for _times_r and _link_r so that code using times()
or link() can still compile. The functions are marked as not implemented
and return invalid codes.
While browsing through the rendered doc, I found the precondition of
`gnrc_netreg_register()` somewhat lacking. What is a "message queue"?
`gnrc_netreg_entry_t`s have types. Does this apply for all types?
This specifies the requirement more: The calling thread **only** needs
a message queue (also provides a link to `msg_init_queue()` now for
further information), if the provided `gnrc_netreg_entry_t` is of type
`GNRC_NETREG_TYPE_DEFAULT` (i.e. thread-wise IPC).
Fix re-register when using the same token.
Handle edge cases when change token for a resource.
Only set observer and resource on initial registration.
Discuss re-registration in documentation.
Otherwise, it may happen that `::` or a global address is chosen by
the IPv6 header fill function. Both types of addresses are
[not valid for RAs](https://tools.ietf.org/html/rfc4861#section-4.2)
Parts of [RFC4862] were already implemented when NDP via the NIB was
first implemented. This change just includes the DAD portion of
[RFC4862]. This should be enough to make RIOT fully RFC4862 compliant.
[RFC4862]: https://tools.ietf.org/html/rfc4862
With #9209 gCoAP got the ability to re-register and OBSERVE with a new
token, sadly the `observer` variable wasn't set in that fix, so a
re-registration actually led to the deletion of the observer (because it
is still `NULL` when the old registration is overwritten in l. 317)
The macro MODULE_TLSF_MALLOC indicates if tlsf is being used as the system-wide
allocator. MODULE_TLSF only incates if TLSF is present.
PS should check for MODULE_TLSF_MALLOC to decide if heap information should be
displayed.
OutputterPrintHeaderFunction is declared as a function of 1 parameter
but CompilerOutputter_printHeader was defined as taking 2.
It is a mystery why this code compiled before.
Currently, `gnrc_pktdump` only prints the header part of a snip.
However, if the snip wasn't parsed yet by the corresponding GNRC
module (or the module doesn't exist because the node is e.g. just a
forwarder), additional data might not be printed.
This makes it hard to analyze the data properly (sometimes you not only
want to know where the IPv6 packet is supposed to go, you also want to
know what's in it). So this just prints the rest of the snip as a hex
dump.
The nanocoap_get function is refactored to split of the request part
into a separate function for reuse by other modules. Support for
retransmissions when the received frame is malformed is dropped as it
was broken anyway.
Provides functions for type 3, 4 and 5 UUID generations.
UUID type 1 is timestamp based and requires an accurate time source. For
this reason it is left out of this implementation. UUID type 2 is not
defined in RFC 4122 and thus also not included here
Reordered struct members to not waste memory due to padding.
Before:
``` C
typedef struct {
uint8_t src_l2addr_len;
uint8_t dst_l2addr_len;
kernel_pid_t if_pid; // <-- 16 bit, is aligned to 16 bit
uint8_t flags;
uint8_t __padding_byte; // <-- Inserted to fulfill padding requirements
int16_t rssi; // <-- 16 bit, is NOT aligned to 16 bit
uint8_t lqi;
uint8_t __padding_byte2;// <-- Inserted to fulfill padding requirements
} gnrc_netif_hdr_t;
```
Now:
``` C
typedef struct {
uint8_t src_l2addr_len;
uint8_t dst_l2addr_len;
kernel_pid_t if_pid; // <-- 16 bit, is aligned to 16 bit
uint8_t flags;
uint8_t lqi;
int16_t rssi; // <-- 16 bit, is aligned to 16 bit
} gnrc_netif_hdr_t;
```
When build for the `bluepill` board, the new layout reduces the size by 2 bytes.
Function is broken with num_bytes >= 4.
Could happen when storing input_len with len_encoding >= 4.
It can take values from 2 to 8, so make it work for cases it would overflow.
Maximum input_len depends only on length_encoding and not auth_data_len.
The current length_max value was also wrong.
RFC3610 page 2
3. The message m, consisting of a string of l(m) octets where 0 <=
l(m) < 2^(8L). The length restriction ensures that l(m) can be
encoded in a field of L octets.
The "new" forwarding table does not update an old route but just adds
another as long as it is not *exactly* the same. However, the RPL
adaptation missed to remove the old route so RPL got easily confused
about where it actually needed to send packets.
