[basic.stc.auto] Limit on the number of variables with automatic storage duration

[cor3ntin]

Issue description:

The standard does not talk about stack. But we should still admit that tape is usually finite.
There was a desire from SG1 to create such an issue (see Wg21kona2022/P2019KONA)

It's unclear how much we want to say, for example, if we want to formulate a note about stack size. But we should say something

(minimalist) Suggested resolution:

Add a new paragraph at the end of [basic.stc.auto]

If the number of variables with automatic storage duration in a block scope exceeds an implementation-defined limit, the behavior of the program is undefined.

[jensmaurer]

We already have Annex B for such implementation limits, and [intro.compliance.general] p2.1 and p9 refers to that Annex. So, we're already in super-UB land here.

Also, the suggested resolution is a bit lacking, because "number of variables" isn't what the limit is about, it's about the total size of objects (not variables) with automatic storage duration.

I'd appreciate if you could rephrase your suggested resolution in terms of Annex B.

[killerbee13]

I think it would be better to write something like

If the program exceeds an implementation-defined limit per thread on the amount of bytes of storage used for objects of automatic storage duration and for storage provided by the implementation when omitting calls to replaceable allocation functions ([expr.new]), the behavior is undefined.

though I'm not particularly happy with the exact phrasing here. I don't know if we can provide a reasonable recommended value here in [implimits] because according to this StackOverflow answer, default stack sizes can be as small as 16kB, and even OS X is under half a megabyte. Also, strictly speaking, this doesn't account for stack frame stuff. We probably want to say that infinite recursion is UB even if it doesn't have any variables.

[frederick-vs-ja]

It seems that the similar concerns also apply to exception objects. The current wording seems to imply that throwing an exception always succeeds if the construction of the exception object always normally returns, but it's perhaps already clear that we can't create unlimited number of exception objects.

[t3nsor]

I don't know if we can provide a reasonable recommended value here in [implimits] because according to this StackOverflow answer, default stack sizes can be as small as 16kB, and even OS X is under half a megabyte. Also, strictly speaking, this doesn't account for stack frame stuff. We probably want to say that infinite recursion is UB even if it doesn't have any variables.

I agree that it's difficult to provide a reasonable recommended value. That being the case, the motivation for even mentioning the quantity that is subject to the limit seems lacking, in my opinion. I don't see any difference between the current world and a future world in which there exists some text in the standard calling out that you can only have so many bytes occupied by automatic storage duration variables, you can only have so many nested calls, you can only have so many bytes occupied by exception objects, etc, other than that CWG will have to divert time to this from something else.

[jensmaurer]

@t3nsor , we'd like to avoid implicit undefined behavior, so I fear we must spend a bit of CWG effort to specify where undefined behavior happens. A limited stack size seems to be such a thing, although I agree it's hard to specify the quantity that's subject to a limit in the first place.

[t3nsor]

@t3nsor , we'd like to avoid implicit undefined behavior, so I fear we must spend a bit of CWG effort to specify where undefined behavior happens. A limited stack size seems to be such a thing, although I agree it's hard to specify the quantity that's subject to a limit in the first place.

I don't think there's implicit UB here. We already give blanket permission for implementations to exhibit UB when any limit is exceeded, even one that isn't explicitly described in [implimits].

If we really feel that we should be more explicit, then the only thing I think there is some justification for adding to [implimits] is a limit on recursion depth, since stack frames don't exist in the abstract machine, so this is the only limit that can be argued to be "surprising" at all. It seems entirely unnecessary to say there are limits on various subsets of abstract machine storage.