[libc-commits] [libc] [libc] Add inet_ntop (PR #204143)

[Pavel Labath via libc-commits]

================
@@ -0,0 +1,53 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+///
+/// \file
+/// Implementation of inet_ntop function.
+///
+//===----------------------------------------------------------------------===//
+
+#include "src/arpa/inet/inet_ntop.h"
+#include "hdr/errno_macros.h"
+#include "hdr/sys_socket_macros.h"
+#include "hdr/types/struct_in6_addr.h"
+#include "hdr/types/struct_in_addr.h"
+#include "src/__support/CPP/span.h"
+#include "src/__support/common.h"
+#include "src/__support/libc_errno.h"
+#include "src/__support/macros/null_check.h"
+#include "src/__support/net/address.h"
+
+namespace LIBC_NAMESPACE_DECL {
+
+LLVM_LIBC_FUNCTION(const char *, inet_ntop,
+                   (int af, const void *__restrict src, char *__restrict dst,
+                    socklen_t size)) {
+  LIBC_CRASH_ON_NULLPTR(src);
+  LIBC_CRASH_ON_NULLPTR(dst);
+
+  bool success;
+  if (af == AF_INET) {
+    success = net::ipv4_to_str(*static_cast<const struct in_addr *>(src),
----------------
labath wrote:

This is potentially problematic. The glibc manpage says the argument must point to a "struct in_addr" -- which would make this okay. However, POSIX is a bit fuzzier and simply says "points to a buffer holding an IPv4 address", which would make this a aliasing violation if the caller uses a different way to represent an "ip address".

https://github.com/llvm/llvm-project/pull/204143