Anonymous | Login | Signup for a new account | 2021-01-21 09:06 UTC | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
0000829 | Taste | [All Projects] ASN.1 Compiler v4 | public | 2019-02-13 09:05 | 2019-02-16 10:02 | ||||||
Reporter | cavada@fbk.eu | ||||||||||
Assigned To | gmamais | ||||||||||
Priority | normal | Severity | feature | Reproducibility | always | ||||||
Status | assigned | Resolution | open | ||||||||
Platform | OS | OS Version | |||||||||
Summary | 0000829: It should be possible to indicate size of encoding | ||||||||||
Description | 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.
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.
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: 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:
| ||||||||||
Tags | No tags attached. | ||||||||||
Attached Files | ![]() ![]() | ||||||||||
![]() |
|
(0003563) 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] |
(0003565) cavada@fbk.eu (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: |
(0003567) 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) cavada@fbk.eu (reporter) 2019-02-13 11:52 |
I see your point. Yes, the encoding function may/should (safely) check and raise when limit is hit. |
(0003569) 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) cavada@fbk.eu (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) cavada@fbk.eu (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. |
(0003572) 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. 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. |
(0003574) gmamais (developer) 2019-02-16 10:02 |
I read all the comments, but I am not really sure what needs to be done here. |
![]() |
|||
Date Modified | Username | Field | Change |
2019-02-13 09:05 | cavada@fbk.eu | New Issue | |
2019-02-13 09:06 | cavada@fbk.eu | File Added: T-Message.png | |
2019-02-13 09:07 | cavada@fbk.eu | 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 | cavada@fbk.eu | Note Added: 0003565 | |
2019-02-13 11:39 | maxime | Note Added: 0003567 | |
2019-02-13 11:52 | cavada@fbk.eu | Note Added: 0003568 | |
2019-02-13 12:07 | maxime | Note Added: 0003569 | |
2019-02-13 12:16 | cavada@fbk.eu | Note Added: 0003570 | |
2019-02-13 12:52 | cavada@fbk.eu | 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 |