Skip to content
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

gitparse: Use an object for currentDiff #1573

Merged
merged 3 commits into from
Jul 31, 2023
Merged

gitparse: Use an object for currentDiff #1573

merged 3 commits into from
Jul 31, 2023

Conversation

mcastorina
Copy link
Collaborator

This is safer than relying on state to ensure we don't get a nil pointer dereference.

@mcastorina mcastorina requested a review from a team as a code owner July 28, 2023 16:42
@mcastorina mcastorina changed the title gitparse: Use an object for currentDiff and currentCommit gitparse: Use an object for currentDiff Jul 28, 2023
Copy link
Contributor

@0x1 0x1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one question, otherwise looks gucci

@@ -309,8 +309,8 @@ func (c *Parser) FromReader(ctx context.Context, stdOut io.Reader, commitChan ch
if currentCommit == nil {
currentCommit = &Commit{}
}
if currentDiff != nil && currentDiff.Content.Len() > 0 {
currentCommit.Diffs = append(currentCommit.Diffs, *currentDiff)
if currentDiff.Content.Len() > 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does making it an object allow us to avoid nil checking? is it just going to default to an empty struct?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. When its initialized it is an empty struct instead of a pointer to nil.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case @bill-rich would it be a pointer to nil or a nil pointer? I think the latter?
This is my understanding:

var i *int = nil // i is a nil pointer
var p **int = &i // p is a pointer to a nil pointer || closest thing to pointer to nil lol

Copy link
Collaborator

@bill-rich bill-rich Jul 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I worded that poorly (wrong). Should have been "pointing to nil".

Copy link
Collaborator

@rosecodym rosecodym left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this lgtm and i'm assuming it doesn't run afoul of @bill-rich's commentary re: pointers on #1570 (because he's commenting here without objecting) but maybe check with him if you haven't already

@mcastorina
Copy link
Collaborator Author

this lgtm and i'm assuming it doesn't run afoul of @bill-rich's commentary re: pointers on #1570 (because he's commenting here without objecting) but maybe check with him if you haven't already

yep, chatted out-of-band and we were already making a copy when we dereferenced it to put in the channel.

@mcastorina mcastorina merged commit b54683a into main Jul 31, 2023
8 of 9 checks passed
@mcastorina mcastorina deleted the diff-obj branch July 31, 2023 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants