tuxji commented on PR #901: URL: https://github.com/apache/daffodil/pull/901#issuecomment-1382077210
> Did you have any chance to look at [#901 (comment)](https://github.com/apache/daffodil/pull/901#discussion_r1067276335) about the alignment issue? There might be an alternative approach that doesn't require making those private field public. As I think I about it more, I'm not even sure comparing those two fields is accurate--I think there might be edge cases where it fails. Yes, I have seen edge cases where comparing those two fields fails (that's why I asked for a better approach). However, I have inserted the following code in Runtime2CodeGenerator.generateCode and SeqCompCodeGenerator.seqCompGenerateCode, set a breakpoint on the "val breakHere" line, debugged TestPadTest.c_padtest_01, and the values of the elemIsKnownToBeAligned, elemAlignmentInBits, and elemShouldAddPadding always stayed the same for every gram object walked: every element was known to be aligned to 8 bits, didn't need padding, and I never saw a 32-bit alignment value on any element. I even tried tailOption instead of headOption and still didn't see a 32-bit alignment value. ```scala val context = gram.context val elem = context.enclosingElements.headOption.orNull if (elem != null) { val name = gram.name val elemName = elem.namedQName.toString val elemIsKnownToBeAligned = elem.isKnownToBeAligned val elemAlignmentInBits = elem.alignmentValueInBits val elemShouldAddPadding = elem.shouldAddPadding val breakHere = elem.namedQName.toString } ``` Nevertheless, Daffodil still inserts 3 fill bytes after a 1-byte hexBinary element in the TestPadTest.s_padtest_01 and TestPadTest.c_padtest_01 cases so the empty sequence inside padhexbinary is definitely causing fill bytes to be inserted: ```xml <xs:complexType name="padhexbinary"> <xs:sequence> <!-- Store variable-length opaque bytes --> <xs:element name="opaque" type="xs:hexBinary" dfdl:lengthKind="prefixed" dfdl:lengthUnits="bytes" dfdl:prefixLengthType="length"/> <!-- Pad "padhexbinary" to a multiple of 4 bytes --> <xs:sequence dfdl:alignment="4" dfdl:alignmentUnits="bytes"/> </xs:sequence> </xs:complexType> ``` Daffodil's schema compiler can't generate any element for the empty sequence because it's empty, but the gram objects don't have alignment fields themselves, so that's why I'm having to compare those private endingAlignmentApprox and priorAlignmentApprox fields. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
