While writing some unit tests in my SUPL client to check that I could detect messages with values that don't meet the constraints in the ASN.1 I discovered the asn_check_constraints` function did not work. I was able to put invalid values into the structure and the function returned a successful validation return code.
When using the last upstream release (v0.9.28) the function did correctly mark the restructuring as invalid.
The constraint check function for SEQUENCE returns early with a successful return code if the first field in the structure has valid values. It fails to check the remaining fields.
While writing some unit tests in my SUPL client to check that I could detect messages with values that don't meet the constraints in the ASN.1 I discovered the asn_check_constraints` function did not work. I was able to put invalid values into the structure and the function returned a successful validation return code.
When using the last upstream release (
v0.9.28) the function did correctly mark the restructuring as invalid.After debugging the issue I discovered a bug at https://github.com/mouse07410/asn1c/blob/vlm_master/skeletons/constr_SEQUENCE.c#L147 which you can compare to the code in
v0.9.28at https://github.com/vlm/asn1c/blob/v0.9.28/skeletons/constr_SEQUENCE.c#L1018The constraint check function for SEQUENCE returns early with a successful return code if the first field in the structure has valid values. It fails to check the remaining fields.
This bug was introduced in this upstream commit: https://github.com/vlm/asn1c/commit/a5972bedae1b329276a3acd41ebbba46bca65a2f#diff-b914b1b3e3a94d285c657aad3ed1b78c2a9c02cb1cd32634118bcb20f2041e63L1067
This PR fixes the bug by correctly returning from the field validation loop only if an invalid value is found.