Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000829Taste[All Projects] ASN.1 Compiler v4public2019-02-13 09:052019-02-16 10:02 
Assigned Togmamais 
PlatformOSOS Version

It should be possible to indicate size of encoding


Consider this example taken from STM specification, where a single message is made of a sequence of packets, whose size change according to each packet type.

max-packets INTEGER (0..255) ::= 84

T-Message ::= SEQUENCE 
    nid-stm T-NID-STM,
    packets SEQUENCE (SIZE (1 .. max-packets)) OF T-Packet

T-Packet ::= SEQUENCE
    -- id and length are encoded in acn
    pbody T-Packet-Body

T-Packet-Body ::= CHOICE
    stm-0   T-Packet-STM-empty-body,
    stm-5   T-Packet-STM5-body,
    stm-8   T-Packet-STM8-body,
    --  ...    
    stm-199 T-Packet-STM-empty-body

The compiler, computes the maximum possible size of T-Message, by computing the size of the largest T-Packet, and multiplying it by the maximum number of packets which may appear in a message.
In the example, the computed size of T-Message is

#define T_Message_REQUIRED_BYTES_FOR_ACN_ENCODING       57983 

However, STM specifies that the maximum size of T-Message is 238 bytes (see attached figures taken from STM subset-058-v320)

Having 57983 instead of 238, is a problem:
- Stack size required to hold the buffer for T-Message is much larger. Consider that 57983 is unfeasible on the embedded target platform
- Documented size is not aligned with the size documented in the specification

In ACN, it shall be possible to indicate the size of encoded SEQUENCE data types.

For example, the acn specification may contain size specifier for T-Message:

T-Message [size 1904]  --<-- 238 bytes
    nid-stm [],
    length T-Message-Length [],
    packets [size length]
TagsNo tags attached.
Attached Filespng file icon T-Message.png [^] (62,829 bytes) 2019-02-13 09:06

png file icon L-Message.png [^] (40,492 bytes) 2019-02-13 09:07

- Relationships

-  Notes
maxime (administrator)
2019-02-13 10:16

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.

(0003565) (reporter)
2019-02-13 10:34

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

maxime (administrator)
2019-02-13 11:39

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.

(0003568) (reporter)
2019-02-13 11:52

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

maxime (administrator)
2019-02-13 12:07

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.

(0003570) (reporter)
2019-02-13 12:16

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).

(0003571) (reporter)
2019-02-13 12:52

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.

maxime (administrator)
2019-02-13 15:18

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.

gmamais (developer)
2019-02-16 10:02

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

- Issue History
Date Modified Username Field Change
2019-02-13 09:05 New Issue
2019-02-13 09:06 File Added: T-Message.png
2019-02-13 09:07 File Added: L-Message.png
2019-02-13 09:45 maxime Description Updated View Revisions
2019-02-13 09:50 maxime Assigned To

=> gmamais

2019-02-13 09:50 maxime Status

new => assigned

2019-02-13 10:16 maxime Note Added: 0003563
2019-02-13 10:34 Note Added: 0003565
2019-02-13 11:39 maxime Note Added: 0003567
2019-02-13 11:52 Note Added: 0003568
2019-02-13 12:07 maxime Note Added: 0003569
2019-02-13 12:16 Note Added: 0003570
2019-02-13 12:52 Note Added: 0003571
2019-02-13 15:18 maxime Note Added: 0003572
2019-02-16 10:02 gmamais Note Added: 0003574

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker