Add a script to execute sanity checks on build system files.
It should prevent bad patterns to re-appear after being cleaned.
Currently adds a check for using the content of `FEATURES` instead of
`USEMODULE`.
Modules should not check the content of FEATURES_PROVIDED/_REQUIRED/OPTIONAL
Handling specific behaviors/dependencies should by checking the content of:
* `USEMODULE`
* maybe `FEATURES_USED` if it is not a module (== not a periph_)
The dependency from eepreg to FEATURES_REQUIRED is already defined in
`sys/Makefile.dep` so should not need to be duplicated in the
application Makefile.
Remove first I2C that is not reachable from the pinout and is not connected to anything. Move I2C1 as the first I2C device.
Update FXOS8700 I2C device in board configuration
This makes doing 'scan-build-analyze' produce an error at execution if
WERROR=1.
When used from `scan-build` it will not procude an error to display the result
webpage.
This correctly defines a `scan-build-analyze` target that does not display the
result webpage.
`scan-build-view` has now been moved to a private target as should not
be used directly.
The handling of displaying the page on the host system and implementing
'scan-build-analyze' are now explicitely done with separate targets and
not double implemented target when in docker or on the host that were executed
twice with different implementations.
RFC3610 states that len_encoding is only valid for "0x0001 ... 0xFEFF"
If 0 < l(a) < (2^16 - 2^8), then the length field is encoded as two
octets which contain the value l(a) in most-significant-byte first
order.
sock_[udp|ip]_recv returns `pkt->size` after pkt was released via `gnrc_pktbuf_release(pkt)`.
This can result in wrong values returned by this functions and thus is not according to its sepecification.
Storing this values before releasing pkt returning the stored values should fix this.
Without this the first packet to a new link-local address will not be
delivered in non-6Lo environments, since the interface is not provided.
With this change, if an internet was provided to the address resolver it
will be stored within an allocated `gnrc_netif_hdr_t`.
At this point [IPv6 already striped](netif strip) the packet of its
netif header, so there is no risk that there will be to, in case it was
provided and the `netif` came from its existence.
