Some functions are missing which would normally cause a warning with most linters and static security analysis tools (e.g. the atoX family, mktemp, etc ...). Pr

Some functions are missing which would normally cause a warning with most linters and static security analysis tools (e.g. the atoX family, mktemp, etc ...). Problem is most people I know don't run external linters (maintaining good linting rules is hard to scale in larger projects and in my >3 decades of writing C only few companies[0] I've seen managed the linting rules as part as their "definition of done"). While I think such rules are a good idea it only makes sense if it is done consistently and depends on how religiously the tooling (duct-tape and "process") enforces them (even so, you're still only one `#ifdef` away from undoing that "safety"). Having GCC[1] now support static analysis is a killer feature for this type of problem. On the other end of the spectrum we have Huawei which instead of linting their code is finding creative ways to trick auditing tools and hide such warnings from auditors: [0] https://news.ycombinator.com/item?id=22712338 https://news.ycombinator.com/item?id=22712338 [1] https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/ https://developers.redhat.com/blog/2021/01/28/static-analysi... [2] https://grsecurity.net/huawei_and_security_analysis https://grsecurity.net/huawei_and_security_analysis