APER support

[ikarso]

Most of the code are a copy of UPER. Decoding is verified against H225/h323.

[brchiu]

Just wondering, is this pull request same as Aligned PER support part of #115 ?

[ikarso]

Hi @brchiu
No, its two different implementations of APER support. Most of the code are probably the same i.e. a copy of UPER version with only a small change of call TYPE_[encode|decode]uper to TYPE[encode|decode]aper. I assume some of the basic function differ more for example per*.c and INTEGER.c.

From a encode/decode APER messages point of view #115 and #125 are hopefully the same :)

[mouse07410]

@ikarso and @persandstrom, I've noticed that this PR is not quite compatible with PR #129, as the latter introduces larger constraints than this one supports.

It seems that the best way to address this would be for @ikarso to update this PR to handle larger constraints.

Comments?

[mouse07410]

Also, @ikarso, shouldn't the command line flags be updated to accommodate APER vs UPER?

[mouse07410]

I've "made peace" between this PR and #129. It's in my fork now. Maybe more validation tests are needed to better exercise both APER and longer constraints, but I leave that part to you, @ikarso and @persandstrom.

[persandstrom]

Ok, thanks @mouse07410

[ikarso]

@mouse07410 Do you mean in the converter-sample.c?
For now -iper/-oper do the unaligned version (as before) and -iaper/-oaper for the aligned.
Do you suggest replaceing -iper/-oper with -iuper/-ouper?

I'm not sure that the best path is to merge many PR. Of course i can merge #129 and #99 (from discussion on #115) if it would be helpful. But i rather see a new PR/branch/fork/.. with combined PRs than to extend #125 .
@vlm Can you give a hint what you prefer?

[mouse07410]

@mouse07410 Do you mean in the converter-sample.c?

No, I mean that both PRs (#125 and #129) are applied to my fork of asn1c, and the disagreements between them have been fixed.

For now -iper/-oper do the unaligned version (as before) and -iaper/-oaper for the aligned.
Do you suggest replaceing -iper/-oper with -iuper/-ouper?

No I do not, because I couldn't care less for this cosmetic issue.

I'm not sure that the best path is to merge many PR.

Well, right now #125 and #129 have been merged in my fork.

Of course i can merge #129 and #99 (from discussion on #115) if it would be helpful.

It would probably be nice, though if #99 matters, I'd rather see it on top of the already-working stuff (like my fork :).

But i rather see a new PR/branch/fork/.. with combined PRs than to extend #125 .

As I said, there is a new fork https://github.com/mouse07410/asn1c.git with most of the outstanding PRs applied and merged when there were inconsistencies between them. The fastest way to get #99 into a working asn1c code is IMHO to submit a PR there.

@vlm Can you give a hint what you prefer?

I know that I would prefer for @vlm to merge those PRs, so I don't need to maintain a fork. But since it doesn't seem to be coming any time soon, I took that upon myself.

You're welcome to either extend #125 with #99 (minding that in my fork #125 has been adjusted to accommodate for #129), or figure a better path if you think it exists.

[mouse07410]

@ikarso your update has been merged, thank you! Perhaps you could add a clean version of #99? ;-)

[mouse07410]

The merge has been completed. #99 is in the master branch of my fork, all the CI tests pass.

[sy2017]

when i use the aper support code to decode a VisibleString like this 05 56 31 2E 30 30,code 05 is the size,i find the decode function OCTET_STRING_decode_aper using 7 bits (range_bits) as a boundary for each character ,i wonder if this treatment matchs the rule of APER,it should be 8bits as a boundary in a VisibleString for APER? @ikarso

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ vlm
❌ ikarso
_{You have signed the CLA already but the status is still pending? Let us recheck it.}