daniel:// stenberg://Mar 10, 2025

Inconsistent octal madness

$ ping 010
PING 010 (0.0.0.8) 56(84) bytes of data.
$ ping 010.1.1.1
PING 010.1.1.1 (8.1.1.1) 56(84) bytes of data.
$ ping 018
ping: 018: Name or service not known
$ ping 18
PING 18 (0.0.0.18) 56(84) bytes of data.
$ ping 018.1.1.1
PING 018.1.1.1 (18.1.1.1) 56(84) bytes of data.
$ ping 18.1.1.1
PING 18.1.1.1 (18.1.1.1) 56(84) bytes of data.

Show threaddaniel:// stenberg://
I'm sitting here trying to make sure the #curl URL parser acts consistently. Which certainly is a challenge...
Mar 10, 2025 at 2:41pmWeb
Show threaddaniel:// stenberg://Mar 10, 2025
This is where I scratch my head: https://github.com/curl/curl/pull/16652
urlapi: treat 0 alone as decimal number in IPv4 address by bagder · Pull Request #16652 · curl/curl

Not as a broken octcal. Regression from b4538ec Extended test 1560 to verify this behavior.

GitHub
Show threadLudwig BehmMar 10, 2025

@bagder you have indeed a strange debian. I can't reproduce decimal conversion with leading 0 on debian testing, either.
Does nsswitch.conf play a role in parsing ip address notation? Or is this only depended on ping version?

I would vote for not accepting any non-decimal notations. Neither octal, nor hex, nor anything else.

Show threaddaniel:// stenberg://Mar 10, 2025
@lbehm I can't remove support for octal/hex without breaking use cases - so I won't
Show threadDan SugalskiMar 10, 2025
@bagder On the upside, if you get curl's URL parser to act consistently it may be the very first one ever. Something to look forward to?