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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Use safe accessor to vector elements #1633
feat: Use safe accessor to vector elements #1633
Changes from 1 commit
ddf5b5a
db13e74
0d4bd3d
0c4b289
1a4841f
fc5c148
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps:
with
file
andline
passed from the invocation point (e.g., https://github.com/igraph/rigraph/pull/1633/files#diff-44d6b09dbc4b7f024f1b2df8dcc51a6e3d489408a6f82def8dd49ffb1bcd5dc4R4610) .There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't properly unwind the "finally" stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still better than undefined behavior.
I don't have a good answer here. Let's draft and iterate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it not only the way to properly unwind the
finally
stack is to calligraph_error()
directly?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the C core we use this approach:
Then
R_get_int_scalar
returns an error code as usual, and can be wrapped inIGRAPH_CHECK
orIGRAPH_R_CHECK
.Would this work for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is what I was thinking about. Thanks.
I'll try this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes in the sense that
igraph_error()
should be used, but normally it is called throughIGRAPH_ERROR
, which ensures returning from the function with an error code, which can then be processed byIGRAPH_CHECK
.In igraph 0.10, the unwinding process can potentially have multiple stages, each of which need to be triggered appropriately. This means that
igraph_error()
should not blindly longjmp. That might leave some stages untriggered.This is why in the R interface we have
IGRAPH_R_CHECK
which must only be used at the top level. Only at this level is it safe to longjmp from the error handler, i.e. to callRf_error()
.IGRAPH_R_CHECK
controls whetherRf_error()
is called byigraph_error()
by setting a global flag.Now one might argue that
R_get_int_scalar()
is (or should be) only called at the top level anyway, so we can forget all about this. (Note that I am not actually sure whether this is true, there might be some non-top-level functions where things like REAL(sexp)[0] are still used!) If you decide to not worry about this, there's a risk that someone will useR_get_int_scalar()
in an inappropriate context in the future, which causes a bug that's only triggered in an error condition, and will be very painful to track down. Thus if you go this route, I recommend clearly documenting what check function is allowed to be called in what context, and perhaps even naming these functions in such a way that any misuse is immediately apparent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure right now how to manage this, but I would think that functions which are have
SEXP
type as argument should be used only in top level functions. Which is also the case forR_get_int_scalar()
. Maybe it make sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that
R_get_int_scalar()
and friends should only be called at the top level and before any finalizers are set up. Also agree to document the purpose and the constraints.