[lwip-devel] [task #14247] socket API: implement recvmsg msg_control support

[Joel Cunningham]

Update of task #14247 (project lwip):

        Percent Complete:                     90% => 50%                    

    _______________________________________________________

Follow-up Comment #23:

Travis CI for clang is showing the follow error:


../../../../lwip/src/../test/unit/api/test_sockets.c:530:13: error: cast from
'u8_t *' (aka 'unsigned char *') to 'struct in_pktinfo *' increases required
alignment from 1 to 4 [-Werror,-Wcast-align]
  pktinfo = (struct in_pktinfo*)CMSG_DATA(cmsg);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../lwip/src/../test/unit/api/test_sockets.c:536:10: error: cast from
'u8_t *' (aka 'unsigned char *') to 'struct cmsghdr *' increases required
alignment from 1 to 4 [-Werror,-Wcast-align]
  cmsg = CMSG_NXTHDR(&msg, cmsg);
         ^~~~~~~~~~~~~~~~~~~~~~~
../../../../lwip/src/include/lwip/sockets.h:162:11: note: expanded from macro
'CMSG_NXTHDR'
          (struct cmsghdr *)((u8_t *)(cmsg) + \


I think we might have a problem with using MEM_ALIGNMENT for ALIGN_H and
ALIGN_D.

I'm somewhat confused why the error is generated for clang on x86_64.  I think
fno-sanitize=alignment is forcing no unaligned access on x86_64, right?  If
so, why is MEM_ALIGNMENT set to 1 for unix port (ports\unix\lib\lwipopts.h or
ports\unix\minimal\lwipopts.h, not sure which the unit test is using)?

Second, I could set ALIGN_H and ALIGN_D to 4 which would be correct for
architectures with 4 byte alignment, but what about architectures with 2 byte
alignment?  I don't have much experience with these architectures.  cmsg_len
(type socklen_t) could end up being a u32 and in a 2 byte architecture, does
this need to start on a 4 byte boundary?  If so, then using MEM_ALIGNMENT
would not work.

If we ever add a cmsg data type that is 64-bits, we'll need to up the
alignment to 8, even though MEM_ALIGNMENT would still be 4 on architectures
like ARM.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?14247>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/