Cast alignment warnings
Russ Allbery
eagle at eyrie.org
Sat May 23 23:23:02 UTC 2015
Julien ÉLIE <julien at trigofacile.com> writes:
> So if I understand well, do we just need doing the following thing?
> (It builds fine, without warning.)
Yup, this patch is correct. (And it looks like you already committed it,
yay!)
> --- storage/timecaf/timecaf.c (révision 9831)
> +++ storage/timecaf/timecaf.c (copie de travail)
> @@ -186,15 +186,16 @@
>
> static TOKEN *PathNumToToken(char *path, ARTNUM artnum) {
> int n;
> - unsigned int t1, t2;
> + unsigned int tclass, t1, t2;
> STORAGECLASS class;
> time_t timestamp;
> static TOKEN token;
>
> - n = sscanf(path, "timecaf-%02x/%02x/%04x.CF", (unsigned int *)&class, &t1, &t2);
> + n = sscanf(path, "timecaf-%02x/%02x/%04x.CF", &tclass, &t1, &t2);
> if (n != 3)
> return (TOKEN *)NULL;
> timestamp = ((t1 << 8) & 0xff00) | ((t2 << 8) & 0xff0000) | ((t2 << 0) & 0xff);
> + class = tclass;
> token = MakeToken(timestamp, artnum, class, (TOKEN *)NULL);
> return &token;
> }
[...]
> I've just come across the following ones:
> buffindexed/buffindexed.c:1051:20: warning: cast from 'char *' to 'GROUPENTRY *'
> increases required alignment from 1 to 8 [-Wcast-align]
> GROUPentries = (GROUPENTRY *)((char *)GROUPheader + sizeof(GROUPHEADER));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I suspect that one could just write this as:
GROUPentries = (void *) &GROUPheader[1]
given that GROUPheader is already a pointer to a GROUPHEADER. I wonder if
that would make the warning go away. (Does GCC on amd64 produce those
warnings? I seem to recall that it doesn't.)
These are all problems with assigning the mmap'd address to a variable
that points to the first element of the structure. A better way of
representing this in C would have been to have a pointer to GROUPENTRY be
the last element of GROUPHEADER, although I'm not sure what other
assumptions that would break, somewhere else.
These alignment cast warnings are mostly because the way that mmap'd data
structures are handled are probably correct in terms of code generation
but aren't represented very well for the C type checker.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers
mailing list