From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5D6C43858288; Thu, 30 Mar 2023 21:24:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D6C43858288 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680211445; bh=ADx/AhpTnJzk/3rGTzd19cXGHFM9ONWs0waFv2+wZWw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eFpCHxQZlNL+x3MGaTvrLlzW7owuX5N7IqIWKqYIjGnRnyQt4QTAep8HE5cP1ify6 InS4jC4OYXKVGOYQiK+RcoJTIuhD0zLcgZRKHiDnn9pmAh83BHi0EC2Y1ScIYOfqvQ fjAMy/sJhH7swXKrQFY+HWvJJZYAnBbKSr0f8rWU= From: "eblake at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug network/30293] Socket API is not alias safe Date: Thu, 30 Mar 2023 21:24:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Version: 2.39 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: eblake at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30293 --- Comment #1 from Eric Blake --- In particular, the intent of the POSIX amendment is that user code (such as this example abridged from 'man 2 bind' on Fedora 37) must compile without compiler diagnostics about an alias violation under default compiler warning levels, and must produce the intended semantics without the compiler mis-optimizing it on the grounds of undefined behavior from an alias violat= ion: #include #include #include #include #include #define MY_SOCK_PATH "/somepath" #define handle_error(msg) \ do { perror(msg); exit(EXIT_FAILURE); } while (0) int main(int argc, char *argv[]) { int sfd, cfd; struct sockaddr_un my_addr; sfd =3D socket(AF_UNIX, SOCK_STREAM, 0); if (sfd =3D=3D -1) handle_error("socket"); memset(&my_addr, 0, sizeof(my_addr)); my_addr.sun_family =3D AF_UNIX; strncpy(my_addr.sun_path, MY_SOCK_PATH, sizeof(my_addr.sun_path) - 1); if (bind(sfd, (struct sockaddr *) &my_addr, sizeof(my_addr)) =3D=3D -1) // compiler must not flag t= his handle_error("bind"); //... } However, other (bad) user code, such as the following, may still trigger undefined behavior, even if the compiler is no longer able to diagnose it because of whatever was done to the structs in order to make the sockaddr.sa_family/sockaddr_un.sun_family aliasing be well-defined behavior: struct sockaddr too_small =3D { .sa_family =3D AF_UNIX }; int sfd =3D socket(AF_UNIX, SOCK_STREAM, 0); bind(sfd, &too_small, sizeof(struct sockaddr_storage)); // BAD - don't = do this; the compiler can't flag this as an aliasing violation, but might be a= ble to flag it for potential out-of-bounds referencing Conversely, POSIX does not intend to require that the various sockaddr* typ= es must be universal aliases (that is, sockaddr* does not have to be synonymous with void* or char*, if an implementation has a way to fine-tune how much it can alias): struct stat *st; struct sockaddr *sa =3D (struct sockaddr *)st; // BAD - compiler may, b= ut not must, flag this as an obvious aliasing violation, as it is not one of the c= asts required by POSIX to be diagnostic-free [If the POSIX amendment is itself inaccurate, the Austin Group welcomes comments on how to improve the wording before Issue 8 is finalized] --=20 You are receiving this mail because: You are on the CC list for the bug.=