Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000543Taste[All Projects] ASN.1 Compilerpublic2016-11-03 09:112018-09-23 09:22
Reportermaxime 
Assigned Togmamais 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Summary0000543:

"WITH COMPONENTS" and ACN

Description

Take these types:

T1 ::= SEQUENCE {
  a BOOLEAN,
  b BOOLEAN OPTIONAL
}
T2 ::= T1 (WITH COMPONENTS {..., b PRESENT}

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:
a) A field which is said to be PRESENT or ABSENT may not require this field at all in the binary packet

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?

Thanks

TagsNo tags attached.
Attached Files? file icon DataView.asn [^] (3,030 bytes) 2016-11-06 17:03
? file icon DataView.acn [^] (1,496 bytes) 2016-11-06 17:03

- Relationships
related to 0000807resolvedgmamais 

Optional field and ACN size determinant

 

-  Notes
(0002736)
gmamais (developer)
2016-11-05 14:25

1) UPER
I am not really sure why it is implemented this way. It is no buggy, in the sense that IsConstraintValid() checks that b is present. If it is not present, then returns an error.

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.

2) ACN
Option 1 is more easier to be implemented and perhaps that's what most users would expect. On the other hand option 2 behaves like uPER if no present-when attribute is provided which is the default behavior in most cases.

I would choose option 1, but again it is you who takes the decisions ;-)

Please tell me you your preffered option. Both are doable.

(0002737)
maxime (administrator)
2016-11-05 14:45

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

(0002738)
gmamais (developer)
2016-11-06 14:22

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)
ACN decoder: handles it as non optional but also sets the exists.field to 1

(0002739)
maxime (administrator)
2016-11-06 17:05

Thanks. The ICD backend however does not seem to be updated.

Check the 2 files attached to the ticket and run

$ asn1.exe -icdAcn out.html DataView.asn DataView.acn

Look at the type CPDU-Cmd
Field cpdu-id is supposed to be always PRESENT according to the ASN.1 file but the Preamble bit is still there.

(0002740)
gmamais (developer)
2016-11-11 16:33

fixed in version 3.3.08.

(0002741)
maxime (administrator)
2016-11-12 10:36

Confirmed, thanks!


- Issue History
Date Modified Username Field Change
2016-11-03 09:11 maxime New Issue
2016-11-03 09:11 maxime Status

new => assigned

2016-11-03 09:11 maxime Assigned To

=> gmamais

2016-11-05 14:25 gmamais Note Added: 0002736
2016-11-05 14:26 gmamais Status

assigned => feedback

2016-11-05 14:45 maxime Note Added: 0002737
2016-11-05 14:45 maxime Status

feedback => assigned

2016-11-06 14:22 gmamais Note Added: 0002738
2016-11-06 14:22 gmamais Status

assigned => resolved

2016-11-06 14:22 gmamais Resolution

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
2016-11-06 17:58 maxime Status

resolved => feedback

2016-11-06 17:58 maxime Resolution

fixed => reopened

2016-11-11 16:33 gmamais Note Added: 0002740
2016-11-11 16:33 gmamais Status

feedback => resolved

2016-11-11 16:33 gmamais Resolution

reopened => fixed

2016-11-12 10:36 maxime Note Added: 0002741
2016-11-12 10:36 maxime Status

resolved => closed

2018-09-23 09:22 maxime Relationship added

related to 0000807



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker