Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD6ma-00FyZd-QL for pgsql-bugs@arkaria.postgresql.org; Mon, 18 Nov 2024 18:47:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tD6mY-006cW2-Ql for pgsql-bugs@arkaria.postgresql.org; Mon, 18 Nov 2024 18:47:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD6mY-006cVt-IJ for pgsql-bugs@lists.postgresql.org; Mon, 18 Nov 2024 18:47:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tD6mW-002Z6u-9T for pgsql-bugs@lists.postgresql.org; Mon, 18 Nov 2024 18:47:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4AIIlQVS3336105; Mon, 18 Nov 2024 13:47:26 -0500 From: Tom Lane To: Denis Feklushkin cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18712: inet value ::2 handling goes not as expected In-reply-to: References: <18712-f787a146022a78e4@postgresql.org> <3065772.1731863111@sss.pgh.pa.us> Comments: In-reply-to Denis Feklushkin message dated "Mon, 18 Nov 2024 08:17:51 +0300" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <3335302.1731955339.0@sss.pgh.pa.us> Date: Mon, 18 Nov 2024 13:47:26 -0500 Message-ID: <3336104.1731955646@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="UTF-8" Content-ID: <3335302.1731955339.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Denis Feklushkin writes: > =D0=B2=D1=81, 17 =D0=BD=D0=BE=D1=8F=D0=B1. 2024=E2=80=AF=D0=B3. =D0=B2 2= 0:05, Tom Lane : >> Hmm ... you are right that that code doesn't do what it seems to >> intend to, because by the time that we get to this logic we have >> i =3D=3D 7 not i =3D=3D 6. >> But I'm not sure if we should change it after >> all this time. We're about as likely to get complaints as kudos, >> I fear. And the output isn't incorrect, just not-per-style. >> = >> I wonder whether ISC ever changed their version? > https://github.com/openbsd/src/blob/f7304f605db8e3a4de0a0d1c1488830678f7= 7517/sys/netinet/inet_ntop.c#L196 > Looks, they don't used 0x0001 check, so, they version was always as inte= nded Well, that's OpenBSD's copy. I thought that the original code was in BIND, but it doesn't seem to be there anymore, though there's this tantalizing hint in the changelog from around 9.7.0: bind-9.18.28/ChangeLog:2635. [bug] isc_inet_ntop() incorrectl= y handled 0.0/16 addresses. However, I tried probing the actual behavior of various systems with the attached test program. I got ::ff -> ::ff ::ff:ff -> ::0.255.0.255 on Linux, macOS, FreeBSD, NetBSD, and OpenBSD. So regardless of original intent, this behavior seems to be the de facto standard. I'm disinclined to make us deviate from it. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-c; name="ntoptest.c"; charset="us-ascii" Content-ID: <3335302.1731955339.2@sss.pgh.pa.us> Content-Description: ntoptest.c #include #include #include #include #include #include int main(int argc, char **argv) { char buf[16]; char formatted[128]; memset(buf, 0, sizeof(buf)); buf[15] = 0xff; inet_ntop(AF_INET6, buf, formatted, sizeof(formatted)); printf("::ff -> %s\n", formatted); buf[13] = 0xff; inet_ntop(AF_INET6, buf, formatted, sizeof(formatted)); printf("::ff:ff -> %s\n", formatted); return 0; } ------- =_aaaaaaaaaa0--