`coap_build_reply()` may return negative values on error or
0 in the no-response case.
Don't use it to calculate a payload offset without checking first.
This eliminates race conditions around unregistering netdevs.
gnrc_netreg_lookup-style functions perform a DEVELHELP check on whether
that lock is held.
The change in 399e25cc was did not have the intended effect: As the
local crates still all defined 0.7 as the riot-wrappers version, that
dependency was actually down- rather than upgraded, and thus did not
effect the stabilizations.
This pulls in versions of previously nightly-only crates that can be
built on 1.65 beta.
The Cargo overrides that direct the resolver to the git repositories are
disabled while the version used in tree also happens to be a released
version of the crates, as it should be the case as per [251].
[251]: https://github.com/RIOT-OS/Release-Specs/issues/251
This will allow more components to build on 1.64 stable, and contains a
fix relevant for https://github.com/RIOT-OS/RIOT/pull/18619.
CoAP modules are held back as they appear to need an even newer nightly
than in the current riotdocker to build without feature declarations.
Previously `shell_commands` was a "catch-all" module that included
shell commands for each and every used module that has a shell
companion. Instead, the new `shell_cmds` module is now used to provide
shell commands as individually selectable submodules, e.g.
`cmd_gnrc_icmpv6_echo` now provides the ICMPv6 echo command (a.k.a.
ping).
To still have a "catch all" module to pull in shell commands of modules
already used, `shell_cmds_default` was introduced. `shell_commands`
depends now on `shell_cmds_default` for backward compatibility, but
has been deprecated. New apps should use `shell_cmds_default`
instead.
For a handful of shell commands individual selection was already
possible. Those modules now depend on the corresponding `cmd_%` module
and they have been deprecated.
This will ignore files named `core` and `core.*` (except `core.c`,
`core.h`, `core.md`, `core.txt`) placed directly in the application
folder. This is where `make` is typically called and core dump due to
a crashing native application, flashing tool, or GDB would be placed.
The pattern is intentionally quite narrow, as there is e.g. a core
source folder that should still be monitored.
File systems should be mounted via `vfs_default`, not manually by
the application.
Also, `vfs` gained the `format` sub-command, so no need to provide
it in the example application.
