Bluesim: Fix function call arguments in debug function #702
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
EventQueue::print()
function was callingbk_clock_name()
with the wrong number of arguments, resulting in the warning reported in #698:If the
print()
function were ever called, this would probably segfault. Fortunately,print()
is not used anywhere, as it only exists for use when debugging.Originally, Bluesim only had one global simulation state, but to support having multiple simulations running in the same program, the Bluesim kernel functions were changed to take a pointer to the simulation state (
tSimStateHdl
). It's likely that, during that change, theprint()
function -- and theextern
declaration forbk_clock_name
-- was overlooked.This PR fixes the
extern
declaration to have the right arguments, by adding atSimStateHdl
argument. Theprint()
method then needs to have atSimStateHdl
argument, to be able to pass to the call tobk_clock_name
.That resolves the warning. Although we also could have resolved the warning by deleting
print()
and theextern
declaration, since it's unused.I notice that many functions in the
EventQueue
class take thetSimStateHdl
as an argument. I don't believe that we need a singleEventQueue
to support multiple simulations, so it might make sense for theEventQueue
constructor to take the simulation state and store it, and then the function calls wouldn't need it as an argument. That would be a bigger change than I'm prepared to do now, though.