On 2024-05-29 23:56, Stephen Hemminger wrote:
On Mon, 27 May 2024 13:11:51 +0200
Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:

#ifdef RTE_USE_CC_MEMCPY
+static inline void
+rte_mov16(uint8_t *dst, const uint8_t *src)
+{
+       memcpy(dst, src, 16);
+}
+
+static inline void
+rte_mov32(uint8_t *dst, const uint8_t *src)
+{
+       memcpy(dst, src, 32);
+}
+
+static inline void
+rte_mov48(uint8_t *dst, const uint8_t *src)
+{
+       memcpy(dst, src, 48);
+}
+
+static inline void
+rte_mov64(uint8_t *dst, const uint8_t *src)
+{
+       memcpy(dst, src, 64);
+}
+
+static inline void
+rte_mov128(uint8_t *dst, const uint8_t *src)
+{
+       memcpy(dst, src, 128);
+}
+
+static inline void
+rte_mov256(uint8_t *dst, const uint8_t *src)
+{
+       memcpy(dst, src, 256);
+}
+
+static inline void *
+rte_memcpy(void *dst, const void *src, size_t n)
+{
+       return memcpy(dst, src, n);
+}
+#endif /* RTE_USE_CC_MEMCPY */
+
+#ifdef __cplusplus
+}
+#endif

You may need to make these macros to fully engage the checking
options of GCC, fortify, coverity etc. Not sure if all the tools
are smart enough to see through an inline.

At least GCC is, provided you compile with optimization enabled. That goes for both overlapping memcpy() warning and static buffer overruns.

clang doesn't warn about overlapping memcpy() and fails to follow function calls, even with optimization enabled, seemingly. Same for ICX.

Static analysis tools that can't beat the compiler seems like they would be of limited use.

With macros you'll lose the type checking, which in the rte_memcpy() case doesn't matter, but rte_mov*() case it does.

I'll sure it break something to change this to macros, although it would be good if clang would also generate a warning (for application code using <rte_memcpy.h>).

Reply via email to