[
https://issues.apache.org/jira/browse/DAFFODIL-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021929#comment-18021929
]
Steve Lawrence commented on DAFFODIL-3021:
------------------------------------------
There are a number of places where the code generator converts expressions to C
code. Here are some of them:
dfdl:length expression:
https://github.com/apache/daffodil/blob/main/daffodil-codegen-c/src/main/scala/org/apache/daffodil/codegen/c/generators/CodeGeneratorState.scala#L439
dfdl:choiceDispatchKey expression:
https://github.com/apache/daffodil/blob/main/daffodil-codegen-c/src/main/scala/org/apache/daffodil/codegen/c/generators/CodeGeneratorState.scala#L821
dfdl:occursCount expression:
https://github.com/apache/daffodil/blob/main/daffodil-codegen-c/src/main/scala/org/apache/daffodil/codegen/c/generators/CodeGeneratorState.scala#L966
accessing a field in an expression:
https://github.com/apache/daffodil/blob/main/daffodil-codegen-c/src/main/scala/org/apache/daffodil/codegen/c/generators/CodeGeneratorState.scala#L1008
Each of these have different limitations and assumptions. Those are good places
to start looking to make the necessary changes. If you have any questions, let
us know more specifically what changes you want to make and we can find the
right spot or come up with an approach.
Note that at a high level there are sort of two general approaches to
generating the C expressions we need.
The first option, and probably the easiest and what I would recommend you do,
is to just tweak the appropriate functions above to add the features you need.
That's probably easier said than done since the current code kind of just tries
it's best and makes lots of assumptions, so each change made needs to consider
those current assumptions. But for example, instead of assuming there is only a
single "../" to access a field, we could count the number of "../"s and add the
appropriate number of "->parent" pointers to the expression. So if there are
three "../"s, we add two "->parent"s. Something like that would help to support
looking at parent/gradparent/etc elements. It's also reasonable to continue to
make assumptions that expressions have some basic level of simplicity--the goal
shouldn't be to support all possible expressions as that will just be too
difficult.
The second option, and likely more work, but probably could support much more
complex expression, would be to recursively walk the tree of objects that
Daffodil creates when it compiles expressions and then convert those to C
expressions. This is very very similar to how the code generator currently
recursively walks the daffodil Grammar to generate all the code here:
https://github.com/apache/daffodil/blob/main/daffodil-codegen-c/src/main/scala/org/apache/daffodil/codegen/c/DaffodilCCodeGenerator.scala#L261-L309
The main difference is instead of matching on "Grammars" you would might match
on "Expressions" or "CompiledDPath". As a real basic example, you might have
something like:
{code:scala}
def generateExpression(curDpath): Unit =>
curDpath.match {
case IF => {
val predicateStr = generateexpression(IF.predRecipe)
val thenStr = generateExpression(IF.thenPartRecipe)
val elseStr = generateExpression(IF.elsePartRecipe)
s"if ($predicateStr) { $thenStr } else { $elseStr }
}
case ....
}
{code}
Note that I'm sure this code doesn't actually work, but it's an example of what
it might look like to recursively generate an C expression string. This
approach is probably much more work, so I probably wouldn't recommend it unless
the first approach starts running into difficulties. I imagine someday we'll be
forced to go down this approach, but I probably wouldn't recommend it for
now--I imagine the changes you need are relatively minor and wouldn't need the
added complexity.
> Unbounded occurrences in C code generation
> ------------------------------------------
>
> Key: DAFFODIL-3021
> URL: https://issues.apache.org/jira/browse/DAFFODIL-3021
> Project: Daffodil
> Issue Type: Request
> Reporter: Ben Cavanagh
> Priority: Major
> Attachments: schema.dfdl.xsd
>
>
> Wanted to request (or ask whether it is possible through some other method)
> the ability to generate C code which is capable of handling unbounded
> occurrences of a type. I've attached a schema which parses strings of "0"s of
> unbounded length.
> I have also tried setting a high bound for maxOccurs and the code
> successfully generates but does not make.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
