https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100417
--- Comment #2 from John Marshall ---
See also https://github.com/samtools/htslib/pull/1275#issuecomment-831799708
(onwards) and https://github.com/samtools/htslib/pull/1280 for the initial
observation of this in James's original code. The diagnostic message was
cram/cram_codecs.c: In function 'cram_xdelta_encode_char':
cram/cram_codecs.c:1916:19: error: 'cp_end' may be used uninitialized
[-Werror=maybe-uninitialized]
1916 | cp += c->vv->varint_put32(cp, cp_end,
zigzag16(c->u.e_xdelta.last));
which initially misled us into investigating the cp_end pointer itself's
initialisation. IMHO the diagnostic would be more accurate as something like
"data pointed to by 'cp_end' may be used uninitialized".
For code like James's example,
extern void fill(char *start, const char *end);
...
char *dat = malloc(10);
...
fill(dat, dat+10);
in which the 'end' value is demonstrably one-past-the-end-of the malloced
array, it should be clear that the pointed-to data is not going to be read (or
if it was read, the warning should be something more severe!). It seems to me
that in this case the warning is always going to be a false positive so should
be suppressed.
> I've become convinced that attribute access none with no size argument should
> not expect the pointer points to an object of nonzero size.
+1 to this; we also observed that adding access(none, end) caused other
spurious error messages.
I suppose there is no real need for the end parameter to be const char *, and
making it char * like the other pointer parameter into the same buffer does
prevent the warning. So in general that may be the best way to avoid this issue
without resorting to attributes. Unfortunately in the case of varint_put32()
making that change would require making similar changes to a surprisingly large
number of sibling functions across the project's (and a submodule's) source
files.
