Skip to content

index: replace map macros with inline functions #5351

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

Merged
merged 2 commits into from
Jan 16, 2020

Conversation

pks-t
Copy link
Member

@pks-t pks-t commented Jan 9, 2020

Traditionally, our maps were mostly implemented via macros that had
weird call semantics. This shows in our index code, where we have macros
that insert into an index map case-sensitively or insensitively, as they
still return error codes via an error parameter. This is unwieldy and,
most importantly, not necessary anymore, due to the introduction of our
high-level map API and removal of macros.

Replace them with inlined functions to make code easier to read.

@pks-t
Copy link
Member Author

pks-t commented Jan 9, 2020

I've amended another commit that goes into the same direction, but fixes a real bug where we'd always try to resize index maps twice on case-insensitive systems by accident.

src/index.c Outdated
GIT_INLINE(int) index_map_set(git_index *idx, git_idxmap *map, git_index_entry *e)
{
if (!map)
map = idx->entries_map;
Copy link
Member

Choose a reason for hiding this comment

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

I found it a little odd that it took an idx and a map and did this switch. Maybe splitting this into two functions?

int index_map_set(git_idxmap *map, git_index_entry *e, bool ignore_case)

and

int index_entry_set(git_index *idx, git_index_entry *e) which calls into that? Names provisional, of course.

I have the same feelings about index_map_resize...

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I know, I was pondering the same. I guess I'll just go with index_map_set, not even introducing a second index_entry_set. The additional boilerplate isn't even worth it to skip a single parameter, if you ask me. Will update in a few minutes

pks-t added 2 commits January 14, 2020 07:46
Traditionally, our maps were mostly implemented via macros that had
weird call semantics. This shows in our index code, where we have macros
that insert into an index map case-sensitively or insensitively, as they
still return error codes via an error parameter. This is unwieldy and,
most importantly, not necessary anymore, due to the introduction of our
high-level map API and removal of macros.

Replace them with inlined functions to make code easier to read.
Depending on whether the index map is case-sensitive or insensitive, we
need to call either `git_idxmap_icase_resize` or `git_idxmap_resize`.
There are multiple locations where we thus use the following pattern:

	if (index->ignore_case &&
	    git_idxmap_icase_resize(map, length) < 0)
		return -1;
	else if (git_idxmap_resize(map, length) < 0)
		return -1;

The funny thing is: on case-insensitive systems, we will try to resize
the map twice in case where `git_idxmap_icase_resize()` doesn't error.
While this will still use the correct hashing function as both map types
use the same, this bug will at least cause us to resize the map twice in
a row.

Fix the issue by introducing a new function `index_map_resize` that
handles case-sensitivity, similar to how `index_map_set` and
`index_map_delete`. Convert all call sites where we were previously
resizing the map to use that new function.
@pks-t pks-t force-pushed the pks/index-map-macros branch from a859fff to 7fc97eb Compare January 14, 2020 06:46
@ethomson ethomson merged commit a129941 into libgit2:master Jan 16, 2020
@pks-t pks-t deleted the pks/index-map-macros branch January 17, 2020 07:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants