On 6/5/21 4:27 PM, Victor Yodaiken wrote:

On Sat, Jun 5, 2021 at 9:51 AM Tom Honermann <tom@honermann.net> wrote

Why is it not desirable?

I mentioned that there is a tradeoff between code efficiency and safety in the updates made to the paper. 

maybe im looking at the wrong version but i dont see any discussion of that

From here.  Start reading at the paragraph that begins with "Additional motivation for distinct integer types is the ability to specify them as non-aliasing types".

> The following example code would be well-formed in C regardless of whether char8_t is specified as a new integer type or as a typedef name of an existing character type. If char8_t is specified as a typedef name of an existing character type, then the example also works as expected because it does not violate aliasing rules. However, if char8_t is specified as a new integer type, then the example would exhibit undefined behavior because an object of type char is accessed using the char8_t type (assuming no new special provisions added to C17 6.5, Expressions, paragraph 7). Thus, there is a trade-off between code efficiency and safety inherent in how char8_t is defined.

Thank you, good suggestion.

I updated the "typedef name vs a new integer type" section and have now submitted the paper to 

That seems more useful. What is the purpose of creating more type restrictions?

The usual reasons; a coherent object model enables type based analysis for improved code generation and other forms of static analysis. 

What makes it coherent to have unnecessary type ub?
What evidence shows tbaa improves performance on real programs?
My concern is that there is too much ub in the standard already

I'm not going to debate this here as other forums are better suited for discussing the pros and cons of the C object model.  I'm confident WG14 is well positioned to make a decision with regard to this paper.