[
https://issues.apache.org/jira/browse/DAFFODIL-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456514#comment-17456514
]
Steve Lawrence commented on DAFFODIL-2608:
------------------------------------------
> One of the things we definiitely need to do is define an API for this
> layering stuff that doesn't expose the wrong state objects.
Yep, because the LayerRuntimeInfo contains a ParseOrUnparseState, I think the
API needs to treat it just like a PState or UState instance. I.e. it should
never really be stored by layers (just like how PState/UState are never stored
by parser/unparsers). Instead, it should always be passed in when to functions
that might be needed. This allows Daffodil to change the LayerRuntimeInfo as
needed, like when we need to use a UStateForSuspension rather than a UState.
We unfortunately can't force implementations to not store the LayerRuntimeInfo
like they do now, but if it's passed into all the functions then they should
never need to do that, and the API implies (and can document) that one
shouldn't store it.
> PCAP fails with Daf 3.2.0 and IPv4 layers with checksum
> -------------------------------------------------------
>
> Key: DAFFODIL-2608
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2608
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 3.2.0
> Reporter: Mike Beckerle
> Priority: Critical
>
> Updating PCAP to use the new ethernetIP with IPv4 (and Daffodil 3.2.0) is
> failing.
> Please look at https://github.com/DFDLSchemas/PCAP/pull/15
> Or you can clone my repo: [email protected]:mbeckerle/PCAP.git
> Checkout master branch
> $ sbt
> > testOnly *.TestPCAP -- --tests=test_pcap_test_dns
> Will reproduce the error.
> That test used to be a parserTestCase with roundTrip onePass. However, I have
> temporarily converted it into an unparserTestCase with roundTrip 'none' to
> isolate that this bug is only when unparsing.
> I think this is a Daffodil 3.2.0 bug.
> However, I recall somewhere bugs/errors like this being discussed not too
> long ago.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
