Bugfix: set the next-header flag correctly in a stack as parameter#1076
Conversation
|
Error while checking build/O2/o2-dev-fairroot for 5951ace1c21fc0fbf9018a0b0a6f6b1e8fb2044d: Full log here. |
|
Error while checking build/o2checkcode/o2 for 5951ace1c21fc0fbf9018a0b0a6f6b1e8fb2044d: Full log here. |
|
Error while checking build/O2/o2 for 5951ace1c21fc0fbf9018a0b0a6f6b1e8fb2044d: Full log here. |
|
Error while checking build/o2/macos for 5951ace1c21fc0fbf9018a0b0a6f6b1e8fb2044d: Full log here. |
There was a problem hiding this comment.
thinking more about this, I would probably add a bounds check in the infect function, by adding the capacity as parameter and checking that there is enough space, what do you think, @mkrzewic ?
There was a problem hiding this comment.
Hi, at first sight I think a bounds check should not be necessary since the complete buffer size is calculated to be just right...
As for the problem you are trying to solve (thanks for spotting it) I think we need some more type safety there because right now it also takes stuff like arrays and strings: so either restrict the construction of Stack to BaseHeader derived stuff & Stacks AND/OR (in this case) we could add a template specialisation of inject() for Stacks.
There was a problem hiding this comment.
ah, ok, then we should really specialize (or restrict) to BaseHeader derived stuff and Stacks. Since arrays and strings fit seamlessly into inject at the moment, casting those to BaseHeader and setting the flag is another bug. I will update the PR.
There was a problem hiding this comment.
ah, ok, then we should really specialize (or restrict) to BaseHeader derived stuff and Stacks. Since arrays and strings fit seamlessly into inject at the moment, casting those to BaseHeader and setting the flag is another bug. I will update the PR.
There was a problem hiding this comment.
actually we have to exclude everything else than BaseHeader derived stuff in the Stack. We can not guaranty what is in a Stack when we implement specialized versions of inject, and thus we can not set the flags correctly when building a new Stack from additional headers and Stacks. But we rely on that for navigation. So, for our purpose, we have to limit Stack, even though it is in principle more generic.
5951ace to
f6bd3fa
Compare
|
Error while checking build/O2/o2-dev-fairroot for f6bd3fa9b1d30d96a5a59b7b03b1d93a44deee57: Full log here. |
|
Error while checking build/o2checkcode/o2 for f6bd3fa9b1d30d96a5a59b7b03b1d93a44deee57: Full log here. |
The argument list to built up a header stack can be an argument pack of stacks and BaseHeader-derived headers. Since stacks consist of a collection of headers, the next-header flag must be set in the last header of the sequence. Until now, the flag was only set in the first header (where it was already before). Stack itsself is more generic and would also support e.g. arrays and strings. However, in order to support header navigation, Stack is restricted to contain only BaseHeader derived structures. Enforcing this restriction now with a static_assert.
f6bd3fa to
c2405f0
Compare
|
Error while checking build/O2/o2-dev-fairroot for c2405f0: Full log here. |
|
@mkrzewic, I have pushed an update |
|
Error while checking build/o2checkcode/o2 for c2405f0: Full log here. |
|
@matthiasrichter thanks, this should do it. The remaining thing is the ability to construct in place in the correct memory region (aka allocator awareness) and the ability to adopt a buffer (if a receiver, a different device needs to add to the header stack) - I will make that PR once I'm done playing with this concept - soon. |
|
sounds good. so I will merge once the macos CI is finished, the two other failing CIs are unrelated |
|
As for the error in This file seems to be missing. I'm checking whether changing from |
|
Error while checking build/O2/o2 for c2405f0: Full log here. |
- Introducing optional header stack parameter to Output description - Adding helper method to access headers from the header stack at DPL input - removing code duplication This depends on PR AliceO2Group#1076
- Introducing optional header stack parameter to Output description - Adding helper method to access headers from the header stack at DPL input - removing code duplication This depends on PR #1076
- Introducing optional header stack parameter to Output description - Adding helper method to access headers from the header stack at DPL input - removing code duplication This depends on PR AliceO2Group#1076
- Introducing optional header stack parameter to Output description - Adding helper method to access headers from the header stack at DPL input - removing code duplication This depends on PR AliceO2Group#1076
- Introducing optional header stack parameter to Output description - Adding helper method to access headers from the header stack at DPL input - removing code duplication This depends on PR AliceO2Group#1076
Co-authored-by: lserksny <laura.serksnyte@cern.ch>
The argument list to built up a header stack can be an argument pack
of stacks and BaseHeader-derived headers. Since staks consist of a
collection of headers, the next-header flag must be set in the last
header of the sequence. Until now, the flag was only set in the first
header (where it was already before)