Conversation

Notices

1. Embed this notice
   daniel:// stenberg:// (bagder@mastodon.social)'s status on Friday, 10-Jul-2026 01:26:26 JST daniel:// stenberg://

   Today I spotted that musl's inet_ntop() function does not output "::[ipv4]" when asked to output an IPv6 address RFC4291 style. Something both glibc and curl's internal replacements do...

   • Embed this notice
     daniel:// stenberg:// (bagder@mastodon.social)'s status on Friday, 10-Jul-2026 01:26:24 JST daniel:// stenberg://

     in reply to

     • Edwin Török

     @edwintorok @musl sure, but I need consistent output and the deprecated output is still widely supported...

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Friday, 10-Jul-2026 01:26:24 JST Rich Felker

     in reply to

     • Edwin Török

     @bagder @edwintorok @musl This is something we could look at if it makes sense. My understanding was that there was never anywhere ::/96 addresses were ever usable, but there doesn't seem to be any harm in representing them the way they were intended to be represented.

   • Embed this notice
     daniel:// stenberg:// (bagder@mastodon.social)'s status on Friday, 10-Jul-2026 01:26:25 JST daniel:// stenberg://

     in reply to

     • Edwin Török

     @edwintorok POSIX does not mandate that format for 12 leading zero bytes, but several implementations do it as RFC 4291 suggests. @musl makes no attempt to: https://git.musl-libc.org/cgit/musl/tree/src/network/inet_ntop.c?h=v1.2.3

     As I want a stable behavior for curl, I need the same output independently of libc...

   • Embed this notice
     Edwin Török (edwintorok@discuss.systems)'s status on Friday, 10-Jul-2026 01:26:25 JST Edwin Török

     in reply to

     @bagder @musl https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.1 says those addresses are deprecated, and "new or updated implementations are not required to support", also RFC5156 says "these addresses are deprecated and should not appear on the public internet". The `::ffff:ipv4` form does work with musl though (and this form isn't deprecated). I don't know why they deprecated the nicer looking one...
     Although musl does fail one of sortix's https://gitlab.com/sortix/os-test/-/blob/main/basic/arpa_inet/inet_ntop.c the '::89ab..' has some extra '0:0:'.
     Thought about adding a new test case there, but since this form is deprecated it probably doesn't matter what the output looks like.

   • Embed this notice
     Edwin Török (edwintorok@discuss.systems)'s status on Friday, 10-Jul-2026 01:26:26 JST Edwin Török

     in reply to

     @bagder is there an open source POSIX test suite? The Open Group has one, but it isn't open source, so I don't know whether it has a test case for this situation, or if it doesn't, then how to submit one for this bug.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Friday, 10-Jul-2026 01:28:48 JST Rich Felker

     in reply to

     • Edwin Török

     @edwintorok @bagder @musl The failure in the ::89ab.. case should have been fixed by https://git.musl-libc.org/cgit/musl/commit?id=947b4574fa7998f027d3906e1f53acb9a7553c61