https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100417
--- Comment #2 from John Marshall <jmarshall at hey dot com> --- 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.
