On Mon, Jun 13, 2016 at 4:12 PM, Aaron Ballman <aaron.ball...@gmail.com> wrote: > On Mon, Jun 13, 2016 at 6:30 PM, Evgeniy Stepanov <euge...@google.com> wrote: >> eugenis added a subscriber: eugenis. >> eugenis added a comment. >> >> In http://reviews.llvm.org/D20561#446031, @aaron.ballman wrote: >> >>> In http://reviews.llvm.org/D20561#445824, @rogfer01 wrote: >>> >>> > I think I wasn't clear with the purpose of the fix-it: there are a few >>> > cases where getting the address of an unaligned pointer is safe (i.e. >>> > false positives). >>> > >>> > For instance, when I checked Firefox and Chromium there are cases where >>> > getting the address of an unaligned pointer is fine. For the particular >>> > case of these two browsers, they both use a library (usrsctp) that >>> > represents protocol data as packed structs. That library passes addresses >>> > of packed fields to `memcpy` and `memmove` which is OK. >>> >>> >>> I think this is a false-positive that should be fixed. >> >> >> This patch was committed without fixing the false positive case, why? > > Can you give some more code context, like perhaps a test case we can > add to the suite? I believe the current behavior should be essentially > false-positive-free because it only triggers the diagnostic when the > alignments actually differ, so if there are other false-positives, I > agree that we should determine a disposition for them.
This is actually the same library the comment above is talking about: https://bugs.chromium.org/p/chromium/issues/detail?id=619640 >> Could this warning be excluded from -Wall? > > Would you like the warning to be excluded from -Wall even if the > false-positive is fixed? No, the warning seems useful if the false positive is fixed. _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
