rcseacord

Thanks! NCC Group is reselling the online Secure Coding Training and we also deliver instructor-led courses, although these might need to be delivered by webinar until the current crisis abates https://www.nccgroup.trust/us/our-services/cyber-security/se...

No, I usually defer decisions concerning the marketing and availability of the book to the publisher. I try to stick to the areas where I'm actually a knowledgeable expert.

This book has a very concise writing style. I really wanted to keep it small enough to carry on an airplane (when we are allowed to fly again). I'm really proud of the final product and very happy with the editing staff at No Starch who helped me produce a very polished product.

So it's hard to say that I'm the best person to write a modern C book. A slightly lower bar might be, am I the best person who has actually written a modern C Book?

Resume-wise, I've been writing C code since 1985, and I've been an expert on the C Standards Committee (WG14) since 2004. I've written two prior books on C Programming including "Secure Coding in C and C++" and "The CERT C Coding Standard". I also teach Secure Coding in C for NCC Group https://www.nccgroup.trust/us/our-services/cyber-security/se... and I also taught these topics to Computer Science undergraduates and graduate students at CMU for over a decade. So I think I have a good balance of technical skills and communications skills, but you know, pick up a copy and judge for yourself.

I'm checking with No Starch if we have plans to release a sample chapter of this book. There is a list of previous articles I've written including sample chapters from my previous books on Secure Codign in C and C++ and the CERT C Coding Standard here https://www.informit.com/authors/bio/3312572e-d904-45d5-afcd...

Here is a newer article on Uninitialized Reads published by ACM https://queue.acm.org/detail.cfm?id=3041020

Jens and I are both on the C Standards committee. I would definitely say that our books serve different markets.

BudVVeezer and bgtnhz have already made some of my points for me. "EXP05-C. Do not cast away a const qualification" is a recommendation largely because casting away constness isn't undefined behavior. There is a also a rule "EXP40-C. Do not modify constant objects" which defines a normative requirement not to modify constant objects which would result in undefined behavior. The intent of the exception to EXP05-C is to let authors of API constrain how objects of types they expose can be used by users without forcing the same constraints on the implementation. In C++, this can be done by making class members private and providing inline member functions. In C, the options are using opaque types (which has a performance cost because they can only be accessed by non-inline functions defined in the implementation's .c files), or making the struct pointer members const and casting the const away in inline functions. This is safe because the implementer knows that the objects the const pointers do not point to const objects (because the implementation initialized them). We're considering getting rid of the exceptions and risk assessments for recommendations because it suggests that conformance to recommendations is required.

We did actually produce ISO/IEC TS 17961:2013 Information technology -- Programming languages, their environments and system software interfaces -- C secure coding rules http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134

The rules specified in this Technical Specification apply to analyzers, including static analysis tools and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis.

I wrote an article putting all this in some context at: http://www.informit.com/articles/article.aspx?p=2088511