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

Fix a bunch of warnings #4925

Merged
merged 5 commits into from
Jan 17, 2019
Merged

Conversation

lhchavez
Copy link
Contributor

@lhchavez lhchavez commented Jan 6, 2019

This change fixes a bunch of warnings that were discovered by compiling
with clang -target=i386-pc-linux-gnu.

This change fixes a bunch of warnings that were discovered by compiling
with `clang -target=i386-pc-linux-gnu`. It turned out that the
intrinsics were not necessarily being used in all platforms! Especially
in GCC, since it does not support __has_builtin.

Some more warnings were gleaned from the Windows build, but I stopped
when I saw that some third-party dependencies (e.g. zlib) have warnings
of their own, so we might never be able to enable -Werror there.
src/integer.h Outdated
# define git__add_sizet_overflow(out, one, two) \
__builtin_uadd_overflow(one, two, out)
__builtin_add_overflow(one, two, out)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This intrinsic handles whatever sizes you throw at it: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

But with some odd flag combinations in clang, it requires linking against compiler-rt, which was suboptimal. Keeping the chunk in L58-L63 avoided that case and compiled correctly with the intrinsics in all cases I could think of.

It seems like MingW64's size_t is defined differently than in Linux.
@ethomson
Copy link
Member

ethomson commented Jan 8, 2019

Thanks for doing this - there's a lot of unrelated changes in this first commit, and they're not well described, so I'll need a little bit of time to tease things out (ugh all the different printf format descriptors). It looks correct from first glance, and I know the compiler agrees, but I'd just like to have one more set of eyes on it.

That's not meant as a complaint as much as a warning that I'll need some more time to look at this before I merge this, even though it's a rather small PR.

Less controversial changes together is better.
@lhchavez
Copy link
Contributor Author

lhchavez commented Jan 9, 2019

Moved the intrinsics part of the change to #4929 to make it easier to review.

# define PRIxZ "Ix"
# define PRIXZ "IX"
# define PRIdZ "Id"
# endif
Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't be necessary, Id should be 32-bit on 32-bit platforms and 64-bit on 64-bit platforms. It should be the moral equivalent of zd. From MSDN:

The ptrdiff_t and size_t types are __int32 or unsigned __int32 on 32-bit platforms, and __int64 or unsigned __int64 on 64-bit platforms. The I (uppercase i), j, t, and z size prefixes take the correct argument width for the platform.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a comment.

@ethomson
Copy link
Member

ethomson commented Jan 9, 2019

Appreciate you bumping the intrinsics out, that's definitely helpful for reviewing. I think that the printf formatter values need not change to be I64 - were you seeing a warning from those that I'm not seeing immediately?

@lhchavez
Copy link
Contributor Author

lhchavez commented Jan 9, 2019

Yes, on Windows (amd64; MinGW):

2019-01-09T01:28:57.4190283Z D:\a\1\s\src\cache.c: In function 'git_cache_dump_stats':
2019-01-09T01:28:57.4190460Z D:\a\1\s\src\cache.c:51:9: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t' {aka 'long long unsigned int'} [-Wformat=]
2019-01-09T01:28:57.4190545Z   printf("Cache %p: %"PRIuZ" items cached, %"PRIdZ" bytes\n",
2019-01-09T01:28:57.4190613Z          ^~~~~~~~~~~~~
2019-01-09T01:28:57.4190657Z    cache, git_cache_size(cache), cache->used_memory);
2019-01-09T01:28:57.4190696Z           ~~~~~~~~~~~~~~~~~~~~~

this goes away with the formatting change. let me add a comment.

@ethomson
Copy link
Member

Cool, thanks for doing this. Looks good to me.

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.

None yet

2 participants