Concretely for the compiler, what you suggest with this new property is to have in fact a way for the binary encoder to raise an error during the encoding process if the resulting packet reaches this specified size limit ?

In other words right before a new byte is added to the buffer, check the size of the buffer and quit with an encoding error?

I would rather call the property [max-size] rather than [size]
And we could the same way have [min-size] that would be checked after the complete encoding to also raise an error.

No, it is not an issue about runtime check of encoding size.

The goal is to have the compiler generate the right size for buffers in code and documentation. Since the size cannot be inferred, the user shall be enabled to specify it explicitly.

This need is justified as otherwise:
1. The generated cannot be executed in the target (embedded) architecture, as stack size is limited
2. Documentation of the encoding contains wrong information about size of structure

I understand the need for generating macros (and ICDs) that comply to this size specification.

However, unless there is something I miss in your description, my point is that since you cannot enforce the input data to fit in this encoding constraint, the compiler must in addition raise an additional encoding error when it reaches the limit.

I see your point. Yes, the encoding function may/should (safely) check and raise when limit is hit.

Is the stack size not an issue for the local variables of that type as well?

Because of the array they should be even bigger than the binary encoded ones.

In principle yes, for the reason you pinpointed.

But in practice, the instances of that type, will be created out of their encoded bits (238 bytes instead of 57983).

Sorry Maxime, I see your point now.

This is an interesting question for which I need further investigation. Perhaps the sum of sizeof(T_Message) and buffer's size hit the stack limit, or there is something I am missing. I need to ask people who have actually found the stack problem.

However, to me it seems that having the possibility to dictate the size of buffer is a good idea, to limit size and to have correct documentation.

ASN1SCC technically does not generate anything harmful for the stack, since it only generates the macros with the maximum size of the buffers. Encoding and decoding functions only take pointer parameters to place the data after processing, so nothing is declared on the stack.

It's user code that declares the actual buffers - preferably using these macros, but not necessarily.
TASTE uses the macros but declares static/global variables so it should not be causing stack issues in most cases. The only case where buffers are declared on the stack is for unprotected calls - to avoid race conditions in glue code. If you use protected (mutually exclusive, run to completion) calls, there will be no variable declared on the stack.

So the first thing is to check what caused the stack overflow on your side, before touching the compiler.

Now I understand the more important part which relates to the generated ICD. I think we need more than just reporting the size as expressed in the property. If you say that T-Message has a size of 238, the table describing T-Message will still contain the array and other fields, each of these fields having a size potentially bigger than 238 bytes. It will be confusing for the reader of the documentation to understand how this is possible and what is wrong in the table.

The issue is that the encoding specification imposes to the user to know how a particular combination of choices in an array will impact the size of the encoded buffer (while user is not supposed to care about the encoding layout). I don't know how this can be properly described in ASN.1 or ACN except with some comments.

I read all the comments, but I am not really sure what needs to be done here.