svn commit: r300167 - in head: contrib/bsnmp/snmpd usr.sbin/bsnmpd/bsnmpd

[Ian Lepore]

On Thu, 2016-05-19 at 09:43 +1000, Bruce Evans wrote:
> On Wed, 18 May 2016, Ian Lepore wrote:
> 
> > On Wed, 2016-05-18 at 22:02 +0000, Gleb Smirnoff wrote:
> >> Log:
> >>   Revert r299830, it has couple of fatal errors.
> >>
> >>   The CMSG_ family of macros take care of alignment, so we don't
> need
> >> r299830
> >>   at all, even if it was correct.  Put NO_WCAST_ALIGN into
> Makefile.
> 
> The breaks detection of cast-align bugs elsewhere in the program.
> 
> > So all of this was about a "cast increases required alignment" kind
> of
> > warning for a macro that takes care of alignment?  Wouldn't the
> proper
> > fix then be to change CMSG_DATA() so that its internal cast is
> void*
> > instead of unsigned char* (he asked, knowing Bruce would come along
> > soon and point out why that's a dumb question)?
> 
> I don't know much about CMSG*, so I wouldn't have if you didn't ask :
> -).
> 
> Changing its type might expose bugs.  Kernel code mostly casts it so
> would get the same cast-align error if that were enabled in the
> kernel.
> netinet6 passes it to a function without an explicit cast.  The
> function
> does an implicit conversion to a struct pointer and there should be a
> different warning for that.  char * and u_char * are required to be
> binary compatible with void *, but it is bad style to depend on that.
> 
> So void * works better in all cases in the kernel.
> 
> LINUX_CMSG_DATA() already returns void *.
> 
> Bruce
> 

For some reason I had assumed a (void*) cast would wish away the
warning about increasing alignment (without losing that warning at
other places in that code).  Now I can't say for sure why I thought
that would be so, but it does seem to me I've fixed warnings like that
by casting through void* as an intermediate type.  But maybe that was a
different situation/different warning.

-- Ian