Does the issue with Cargo still linking `std` for a `#![no_std]` crate when the
`dev-dependencies` of the crate include something that uses `std` apply to
my project and cause this problem? Or does it not apply because I have no
"cargo features" and/or have no external dependencies?
See:
https://tonyarcieri.com/rust-in-2019-security-maturity-stability#bad-interactions-between-code-classprettyprin_2
examples/ directories with hopefully-realistic examples, including a use of
kul_core from a C program
Make sure all points of fn-call recursion are limited, either inherently or will
need to add manual limiting, to avoid unexpected stack overflow crashes and
instead return error(s) that indicate what happened. Esp. w.r.t. parsing
input texts, which are often untrusted, where our nest form syntax allows
very deep nesting that causes recursion in the parsing.
This will be challenging to do well. Basic numeric limits on nest depth (or
call recursion) aren't a very good way because stack overflow can still occur
if the stack happens to already be significantly consumed, which could be the
case for some users' apps at the points they call our parsing. Knowing how
much stack space is left and dynamically limiting based on that seems like
the only proper way. Need to research these issues and what Rust can do
about them.
Maybe ParseIter::incr_nest_depth could be enhanced somehow to check and enforce
depth/recursion limiting. It could return a Result so an error can be
returned to abort before further call recursion overflows, and it could
delegate the checking to some user- or Rust- or library- provided
functionality that can dynamically check the remaining stack space properly.
Finish/fix doc-comment links. Hopefully the `intra_rustdoc_links` feature (RFC
1946) will become stable soon and can be used to make this task easier and
better.