As further comments, it's unfortunate that this document has chosen certain badly thought out basis documents and concepts.
On page 13 you have a short table of "critical undefined behavior" and an attempt to define "bounded undefined behavior", that ignore all my previous comments in this area, especially the detailed list of cases I sent in reflector message 11499. As I said there: First, there isn't a clear definition of what the bounds are; if you are trying to bound possible behavior, I think it needs to be clear enough to define a set of possible executions in the abstract machine. If people want predictability across implementations, they must stop ignoring the issues and hoping that "undefined but not quite so undefined as all that" will magically solve their problems, and instead seriously put in the weeks or months of work in detailed analysis of every instance of undefined behavior and proper definitions in the abstract machine (that are actually implementable) to bound the possible executions; removing "undefined" does not introduce semantics that were never previously needed or agreed, only careful thought and drafting and textual review work in hundreds of individual cases can do so. The definition in your document fully permits bounded undefined behavior to make daemons fly out of your nose, as that is not an out-of-bounds store. Then you are building on the runtime-constraint mechanism and rsize_t of TR 24731-1. TR 24731-1 is considered useless in the Linux world, and not implemented in the GNU C Library, and with good reason; see <http://sourceware.org/ml/libc-alpha/2007-09/msg00069.html>. If you want general adoption in the Linux world you will need to extract those pieces from the pile of useless, duplicative and prior-art-ignoring functions that is most of TR 24731-1 and demonstrate that despite their background the runtime-constraints and rsize_t have more general utility. -- Joseph S. Myers jos...@codesourcery.com
