On Wed, Jun 24, 2020 at 11:54:20AM -0400, Jeff King wrote:
> > GCC 4.8 complains about this change in our CI job:
> >
> > $ make CC=gcc-4.8 builtin/fast-export.o
> > CC builtin/fast-export.o
> > builtin/fast-export.c: In function ‘generate_fake_oid’:
> > builtin/fast-export.c:394:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
> > put_be32(oid.hash + hashsz - 4, counter++);
> > ^
> > cc1: all warnings being treated as errors
>
> Interesting. The only change on this line is swapping out the local
> "unsigned char *" for an object_id, which also stores an "unsigned
> char" (though as an array). And while put_be32() takes a void pointer,
> it's inlined and treats it the argument an "unsigned char *" internally.
> So I'm not sure I see that any type punning is going on at all.
>
> I'll see if I can appease the compiler, though.
Hmm. Switching to a local array makes the warning go away:
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 4a3a4c93..eae2ec5 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -387,12 +387,12 @@ static void *generate_fake_oid(const void *old, size_t *len)
{
static uint32_t counter = 1; /* avoid null oid */
const unsigned hashsz = the_hash_algo->rawsz;
- struct object_id oid;
+ unsigned char out[GIT_MAX_RAWSZ];
char *hex = xmallocz(GIT_MAX_HEXSZ);
- oidclr(&oid);
- put_be32(oid.hash + hashsz - 4, counter++);
- return oid_to_hex_r(hex, &oid);
+ hashclr(out);
+ put_be32(out + hashsz - 4, counter++);
+ return hash_to_hex_algop_r(hex, out, the_hash_algo);
}
static const char *anonymize_oid(const char *oid_hex)
at the cost of some uglier use of the_hash_algo and RAWSZ. But
curiously, even with the array, if I adjust the write only slightly to
write at the begining instead of the end (we don't really care where our
counter appears in the hash, since the point is to anonymize):
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index eae2ec5..1f52247 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -386,12 +386,11 @@ static void print_path(const char *path)
static void *generate_fake_oid(const void *old, size_t *len)
{
static uint32_t counter = 1; /* avoid null oid */
- const unsigned hashsz = the_hash_algo->rawsz;
unsigned char out[GIT_MAX_RAWSZ];
char *hex = xmallocz(GIT_MAX_HEXSZ);
hashclr(out);
- put_be32(out + hashsz - 4, counter++);
+ put_be32(out, counter++);
return hash_to_hex_algop_r(hex, out, the_hash_algo);
}
...then the warning comes back. I tried that because I was wondering
whether the same thing might make the warning go away on the object_id
version, but it doesn't.
So this really seems like a pointless false positive from the compiler,
and it's a rather old compiler (the warning no longer triggers in gcc 6
and up). Is it worth caring about? Ubuntu Trusty is out of standard
support but not fully EOL'd until 2022. Debian jessie has gcc 4.9
which triggers the warning, but will hit EOL in 5 days. If it were an
actual breakage I'd be more concerned, but keeping such an old compiler
-Werror clean doesn't seem that important.
I'd note also that none of the Actions CI jobs run with this compiler
version. If we _do_ want to care about it, it might be worth covering it
there.
-Peff
