> the loop variable issue could be solved by adding `auto`

I'm not sure how this helps? The compiler doesn't get to choose based on the machine register width – it's bound to choose based on the type of the expression, which is defined by C/C++ integer promotion rules. The expression `0` is an `int` regardless of the context in which it appears, and thus will be an `auto` variable initialized to `0`.

You're better off using `ptrdiff_t` than `auto` for loop indices if you want something sized to native register width.

> The expression `0` is an `int` regardless of the context in which it appears

Not totally true. In C, 0 is a special value that can be an integer or a null pointer literal depending on the context.

> I don't think the performance improvements are worth the security vulnerabilities

This is C++ you're talking about, that's never the right trade-off :P

> the loop variable issue could be solved by adding `auto` and promoting its use - then the compiler can choose the loop counter type appropriate for the machine since the int-as-64-bit ship already sailed

I'm not sure this completely solves the problem, since often you're doing something like this (I know, I know, iterators are the way to do this, but people do write code like this):

  for (int i = 0; i < some_container.size(); ++i) {
  	// do something
  }

Auto doesn't really help here, because if you do something like

  for (auto i = 0; i < some_container.size(); ++i) {
  	// do something
  }

the compiler can't look at your code and say "i really looks like it was meant to be a 64-bit index", it needs to be stupid and deduce it to be an int or at least behave as an int would. Unless I'm misunderstanding what you're trying to say?

> (Clang implements this as `__auto_type` and it harmonizes with C++; I've done #define auto __auto_type in projects and it cleans up a lot of C code quite nicely. I'm somewhat surprised no one has offered it as a solution since it is already a reserved keyword).

Well, you're technically breaking code that actually uses auto the way it was intended to be used, though of course since it's so useless this kind of code is very rare.

> Making signed overflow/underflow trapping behavior would also be acceptable.

You can just add the right compiler flag if this is the right tradeoff for you application (it isn't for everyone).