The Syscall write(buf) message telling that some byte(s) are not initialized
can be caused by writing a struct containing "alignment holes"
that are not initialized. This is not very nice, and should be considered
as a bug (e.g. for reasons of "very unprobable information leak" 
if written on a network, ...).
But when tracking a "functional" bug, having some more info to help
distinguish the "probable" hole from the "looks like a more severe bug"
could be useful. 

So, it would be nice if the error message could provide some more information
so as to be able to differentiate quickly between:
   very suspicious write(buf) (errors that are not a "hole" case)
   slightly suspicious write(buf) (errors that are (maybe) a "hole" case)

A very suspicious write is when there are more than X successive unitialised
bytes being written.
X could be a constant (i.e. the max_needed_alignment-1 for the cpu)
or could be an option to memcheck, e.g.:
   --very_suspicious_write_from=8 

Alternatively, a "--verbose_write_buf" option could produce a detailed
error message giving e.g.:
===  The 16 unitialised bytes are:
===    3 bytes inside buf at offset 21
===    12 bytes inside buf at offset 24
===    1 byte  inside buf at offset 47

The "12 bytes" makes the write error message more suspicious (as
a hole of 12 bytes is unlikely).

Alternatively, a general option --verbose_bytes_indication
could tell to memcheck to always give as much as possible
info about where the uninitialised bytes are.
For example, the "jump or move depends on uninit values"
could then also reports:
   uninit values are at Address 0xDEADBEEF, length 4
(but I suspect that in all/a lot of cases, the uninit value will be
in a register, and so this "general" idea seems pretty useless).