|Anonymous | Login | Signup for a new account||2021-05-12 01:45 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000543||Taste||[All Projects] ASN.1 Compiler||public||2016-11-03 09:11||2018-09-23 09:22|
"WITH COMPONENTS" and ACN
Take these types:
With PER encoding, T2 still has a boolean added that specifies the presence of b. This is because PER ignores subtype constraints.
There are two issues (one possible bug and one feature request):
1) What seems not right is that the type in the .h file also requires the user to set the "exist" field to 1, otherwise the encoding function may ignore the field even if it is supposed to be always PRESENT. Shouldn't the PER encoder ignore the "exist" field and always set the bit to 1 or 0 in the packet based on the subtype constraint?
2) I propose to have a different behaviour with ACN.
There are two options:
b) Add an attribute [present-when] : [present-when subtype-constraint] telling the compiler to take into account the WITH COMPONENT constraint to decide if the bit should be kept or not.
Second option gives more flexibility (PER by default, overriden by explicit ACN directive).
Does that seem feasible?
|Tags||No tags attached.|
|Attached Files|| DataView.asn [^] (3,030 bytes) 2016-11-06 17:03|
DataView.acn [^] (1,496 bytes) 2016-11-06 17:03
If you think that this is still an issue, we can change this behavior by changing the definition of T2 so that it does not have the exists.b field (like if it was not optional). Of course, the isConstraintValid() function will no longer check if it is present and the uper encode/decode functions will handled it as a present optional field. If we make this change, there is a small possibility to break some existing code.
Please tell me if you want to make this change.
I would choose option 1, but again it is you who takes the decisions ;-)
Please tell me you your preffered option. Both are doable.
1) In order not to break existing code (even if the risk is very low), could we perhaps keep the "exist" field but just ignore it in both isConstraintValid and Encode/Decode?
2) I agree with you, I think in practice that option 1 will cover all cases we have now. If in addition it is easier to implement, it is better.
Priority-wise, the second point is more important (since we do have a case).
new feature implemented in version 3.3.07
The type definitions remain the same (so no code break).
The IsConstraintValid() function does not check exists.field when b is always present.
uPER encoder : does not check the exists.field and puts always 1 in the encoded bit mask. The decoder still checks if the bit is set and only then decodes the component.
ACN encoder: does not check the exists.field and does not put any bit (i.e. it handles as non optional)
Thanks. The ICD backend however does not seem to be updated.
Check the 2 files attached to the ticket and run
Look at the type CPDU-Cmd
fixed in version 3.3.08.
|2016-11-03 09:11||maxime||New Issue|
new => assigned
|2016-11-03 09:11||maxime||Assigned To||
|2016-11-05 14:25||gmamais||Note Added: 0002736|
assigned => feedback
|2016-11-05 14:45||maxime||Note Added: 0002737|
feedback => assigned
|2016-11-06 14:22||gmamais||Note Added: 0002738|
assigned => resolved
open => fixed
|2016-11-06 17:03||maxime||File Added: DataView.asn|
|2016-11-06 17:03||maxime||File Added: DataView.acn|
|2016-11-06 17:05||maxime||Note Added: 0002739|
resolved => feedback
fixed => reopened
|2016-11-11 16:33||gmamais||Note Added: 0002740|
feedback => resolved
reopened => fixed
|2016-11-12 10:36||maxime||Note Added: 0002741|
resolved => closed
|2018-09-23 09:22||maxime||Relationship added||
related to 0000807
|Copyright © 2000 - 2011 MantisBT Group|