[PATCH] D68526: [Diagnostics] Silence -Wsizeof-array-div for character buffers

James Clarke via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Oct 6 07:30:43 PDT 2019


jrtc27 added a comment.

In D68526#1696587 <https://reviews.llvm.org/D68526#1696587>, @lebedev.ri wrote:

> There's not a single word in the patch's description.


If I were to add a description, it would be something like:

  Character buffers are sometimes used to represent a pool of memory that
  contains non-character objects, due to them being synonymous with a stream of
  bytes on almost all modern architectures. Often, when interacting with hardware
  devices, byte buffers are therefore used as an intermediary and so we can end
  Character buffers are sometimes used to represent a pool of memory that
  contains non-character objects, due to them being synonymous with a stream of
  bytes on almost all modern architectures. Often, when interacting with hardware
  devices, byte buffers are therefore used as an intermediary and so we can end
  up generating lots of false-positives.
  
  Moreover, due to the ability of character pointers to alias non-character
  pointers, the strict aliasing violations that would generally be implied by the
  calculations caught by the warning (if the calculation itself is in fact
  correct) do not apply here, and so although the length calculation may be
  wrong, that is the only possible issue.

But it seems that this first premise is actually wrong; at least in FreeBSD, and using a quick grep through Linux for obvious names (`sizeof.*buf) /`, `sizeof.*buffer) /` and `sizeof.*data) /`) I couldn't find one instance of an array where the types didn't match, but that was for `u64` vs `u32` so isn't even covered by this. Maybe it was true in the past, but these days people seem to be diligent about using the right types, with proper unions when needed.

The aliasing point still applies (in that this case is slightly less dangerous), but given it draws attention to code that may be able to be written more nicely with better types, I'd be inclined to abandon this. Unless people come screaming that we're spewing too many warnings for their code, that is, of course.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68526/new/

https://reviews.llvm.org/D68526





More information about the cfe-commits mailing list