Ambiguity of setting L and the role of a Raptor10 structure as a source of truth

[Etua]

The Raptor10 structure defines many, if not all packet fields defined in the RFC. Ideally, their values would be trusted from the structure initialisation. Unfortunately that is not the case. The value of L (defined in the structure as well) is recalculated locally in r10_Trip, r10_build_LT_submat and r10_build_LT_mat. This is troublesome, since no indication is given whether this is done on purpose or as an oversight. If the first one is true, shouldn't the value be updated in the structure?

Other problems arise:

1. In r10_build_LT_mat one can only use Raptor10 structure to calculate L, in r10_Trip K is passed as an argument and in r10_build_LT_submat it's K, S and H. All of them get a pointer to the Raptor10 structure. What values should be used in these situations? The ones passed as the arguments or from the structure? Again, if the first ones, why isn't the structure updated? Such mix of pseudo-functional and imperative code is confusing and might introduce errors, that will be very hard to trace. After all, we use some K, S or H each time. If a function is supposed to have the notion of Raptor10, then it probably shouldn't directly adhere to the RFC demanding an argument of K; the reverse is true as well.
2. The malpractice of copy-pasting sections of code contributes to the problem described in Make all values count #13 For example in r10_Trip a local value of L is calculated, but it is never accessed as the line directly under it uses L from Raptor10 structure adding even more complexity and making chances of errors even higher for the reasons described in point number 1. I'd separate these calculations into a separate function already, if not for the fact, that performing this operation in the functions other than the setup is a source of concern already.