* Ensure that `furi_record_create` is passed a non-NULL data pointer
It's currently possible to use `furi_record_create` to create and initialize a `FuriRecordData` pointing to NULL.
This means its potentially possible for `furi_record_open` to return a NULL pointer which besides not being particularly useful means the Rust wrapper for `Record` can't assume that the returned record is always a non-NULL value.
If by chance this is the intended behaviour, then we can just have the Rust wrapper do a `furi_check` itself, but it seems like it would be better to eliminate this potential corner-case at the source.
* Furi: update furi_record_create documentation
Co-authored-by: あく <alleteam@gmail.com>
* Remove unnecessary checks
* Sublime: never insert missing headers
* Cleanup furi defines use
* Cleanup startup. Cleanup linker scripts. Explicitly define all interrupts hadlers, including uninmplemented one.
* Startup routine in C
* Drop assembler startup
* Move linker defines to stm32wb55_linker.h, cleanup naming, unify usage. Mpu: protect last 32b of main stack. Document various obscure things.
* Move furi_hal_switch documentation to appropriate place, use 0x0 for updater jump.
* UnitTests: move all temporary test files into tmp folder
---------
Co-authored-by: SG <who.just.the.doctor@gmail.com>
* Api Symbols: replace asserts with checks
* Api Symbols: replace asserts with checks part 2
* Update no args function signatures with void, to help compiler to track incorrect usage
* More unavoidable void
* Update PVS config and code to make it happy
* Format sources
* nfc: fix checks
* dead code cleanup & include fixes
Co-authored-by: gornekich <n.gorbadey@gmail.com>
Co-authored-by: hedger <hedger@users.noreply.github.com>
Co-authored-by: hedger <hedger@nanode.su>
