Sören Krecker <soekkle@xxxxxxxxxx> writes: > Fix compiler warings from msvc in date.c for value truncation from 64 > bit to 32 bit integers. > > Also switch from int to size_t for all variables with result of strlen() > which cannot become negative. > > Signed-off-by: Sören Krecker <soekkle@xxxxxxxxxx> > --- > commit.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/commit.c b/commit.c > index 35ab9bead5..3d363260f3 100644 > --- a/commit.c > +++ b/commit.c > @@ -466,8 +466,8 @@ int parse_commit_buffer(struct repository *r, struct commit *item, const void *b > struct object_id parent; > struct commit_list **pptr; > struct commit_graft *graft; > - const int tree_entry_len = the_hash_algo->hexsz + 5; > - const int parent_entry_len = the_hash_algo->hexsz + 7; > + const size_t tree_entry_len = the_hash_algo->hexsz + 5; > + const size_t parent_entry_len = the_hash_algo->hexsz + 7; We saw another change around hexsz in this series, but I seriously doubt that it is sensible to define .hexsz member of git_hash_algo as type size_t. The whole _point_ of hash function is so that it can be represented by a handful of bytes, so insisting size_t and forcing us to suffer code churning like we see here is simply crazy. Would it work equally well, if not better, if you instead fixed the type of the .hexsz member (and its friends) to something more reasonable, like "int"?
