[lwip-devel] [bug #63324] memcpy(), memmove() and other libc dependencies

[Faidon Liambotis]

URL:
  <https://savannah.nongnu.org/bugs/?63324>

                 Summary: memcpy(), memmove() and other libc dependencies
                 Project: lwIP - A Lightweight TCP/IP stack
               Submitter: paravoid
               Submitted: Sun 06 Nov 2022 07:13:37 PM UTC
                Category: Platform ports
                Severity: 3 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sun 06 Nov 2022 07:13:37 PM UTC By: Faidon Liambotis <paravoid>
In 2007 (commit 255d5a74, v1.3.0) the MEMCPY and SMEMCPY macros were
introduced
with this description:
    2007-05-09 Simon Goldschmidt
    * opt.h, *.c/*.h: Included patch #5920: Create define to override
C-library
      memcpy. 2 Defines are created: MEMCPY() for normal memcpy, SMEMCPY()
for
      situations where some compilers might inline the copy and save a
function
      call. Also replaced all calls to memcpy() with calls to (S)MEMCPY().

In 2017 (commit 7cedf7ae) MEMMOVE was also added along the same lines.

A few direct (lowercase) uses have creeped in since. I am working on a project
with NO_SYS=1, that should build without a libc available, and I am defining
MEMCPY and MEMMOVE to internal reimplementations of these functions. I hit on
memcpy() being directly used in ip6addr_ntoa_r (ip6_addr.c) and memmove() in
lwip_itoa (def.c). Grepping through the tree reveals a few more (but
fortunately not too many). These should probably be replaced with the already
existing MEMCPY and MEMMOVE macros.

Additionally it would be good to define and use other string.h macros like
MEMCMP and MEMSET. I ran into on memcmp() in eth_addr_cmp (ethernet.h), and
memset() in netif_add (netif.c), tcp_alloc (tcp.c), udp_new (udp.c),
ip_reass_enqueue_new_datagram (ipv4/ip4_frag.c), ip6_reass (ipv6/ip6_frag.c),
dns_send (dns.c), plus a few uses in ipv4/dhcp.c. Finally, I also ran into
strlen() and strncmp() in pbuf_strstr (pbuf.c), lwip_strnstr (def.c) as well
as strlen() in dns_send (dns.c). It does feel a bit like a game of
whack-a-mole, so I am curious how you feel this compares to the existing
facilities (MEMCPY/MEMMOVE), and if there are other recommendations for
systems where a libc is unavailable.

In all of those cases, it looks like there is an #include <string.h> in the
source files. Given this exists solely for those functions above, it'd be nice
to avoid it, especially in NO_SYS mode. For what it's worth, on a simple
NO_SYS=1 configuration, these 6 (memcmp, memset, strlen, strncmp, plus
memcpy/memmove) are enough to avoid string.h altogether.

That, plus atoi() in stdlib.h are the only libc dependencies that I had to
workaround for my build. (I wonder if I should file a separate bug for atoi?)

Finally, I am also unsure why these macros live in lwipopts.h rather than
cc.h? The distinction between the two feels somewhat blurry, but my
understanding is that it may fit better in cc.h.







    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?63324>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/