[ASIO] Resolver question
I have some pretty simple UPD code. (It has to be simple, I'm new at ASIO) boost::asio::ip::udp::resolver::query query(boost::asio::ip::udp::v4(), addr, port); m_receiverEndpoint = *m_resolver.resolve(query); If my address is 192.168.1.112 everything works If my address is 192.168.001.112 it doesn't work and throws an exception about not finding the host. It's not a big deal, but it sure took me a long time to track down. Is there some sort of Boost magic I can do to convert the bad address into a good address? Thanks, John ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
On 25/02/2016 11:36, Davies, John wrote:
If my address is 192.168.1.112 everything works
If my address is 192.168.001.112 it doesn’t work and throws an exception about not finding the host.
It’s not a big deal, but it sure took me a long time to track down.
Is there some sort of Boost magic I can do to convert the bad address into a good address?
Can you change whatever is formatting the address incorrectly in the first place? I can't think of any system function that would generate addresses in that format, so presumably that's coming from something app-specific.
I can do that. I have it in a masked text box but really a regular text box would be just as good for this application. -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: Wednesday, February 24, 2016 6:00 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [ASIO] Resolver question On 25/02/2016 11:36, Davies, John wrote:
If my address is 192.168.1.112 everything works
If my address is 192.168.001.112 it doesn't work and throws an exception about not finding the host.
It's not a big deal, but it sure took me a long time to track down.
Is there some sort of Boost magic I can do to convert the bad address into a good address?
Can you change whatever is formatting the address incorrectly in the first place? I can't think of any system function that would generate addresses in that format, so presumably that's coming from something app-specific. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
On 25/02/2016 12:24, Davies, John wrote:
I can do that. I have it in a masked text box but really a regular text box would be just as good for this application.
You could use one of these: https://msdn.microsoft.com/library/windows/desktop/bb761372 It's available in recent MFC too, and there's probably a WinForms wrapper around somewhere.
On 25/02/2016 12:24, Davies, John wrote:
I can do that. I have it in a masked text box but really a regular text box would be just as good for this application.
You could use one of these: https://msdn.microsoft.com/library/windows/desktop/bb761372
It's available in recent MFC too, and there's probably a WinForms wrapper around somewhere. But that's still just a workaround, isn't it? 192.168.001.112 looks a
On 25.02.2016 00:43, Gavin Lambert wrote: perfectly good dotted-decimal address to me. I would recommend filling a bug report. Best, Leon
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 25/02/2016 12:55, Leon Mlakar wrote:
But that's still just a workaround, isn't it? 192.168.001.112 looks a perfectly good dotted-decimal address to me.
What does 192.168.077.112 mean? Is the third value 77 or 077==63? The usual convention for 0-prefixed numbers is to treat them as octal.
On 25.02.2016 01:45, Gavin Lambert wrote:
On 25/02/2016 12:55, Leon Mlakar wrote:
But that's still just a workaround, isn't it? 192.168.001.112 looks a perfectly good dotted-decimal address to me.
What does 192.168.077.112 mean? Is the third value 77 or 077==63? The usual convention for 0-prefixed numbers is to treat them as octal. Granted, there is some potential for ambiguity. Still, the name dotted-decimal format does imply base 10. Octal was even used for a brief period ages ago, but was soon abandoned. Personally I've never seen octal to be used for IP addresses. Come to think of it, never seen octal used for any other purpose than academic exercise.
Ancient "Assigned Numbers" RFCs, on the other hand, listed 0 prefixed IP addresses interpreted as decimal numbers. I can understand how 192.168.001.112 came to be - such strings are often a result of ill-conceived web or GUI forms, which design four three-digit input fields and 0 prefix numbers to get required field width. From this point on, the arguments can go both ways. I argue that for user convenience the library should accept such addresses and interpret them according to common practice. And document the interpretation, naturally. Cheers, Leon
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 02/25/2016 12:55 AM, Leon Mlakar wrote:
But that's still just a workaround, isn't it? 192.168.001.112 looks a perfectly good dotted-decimal address to me.
That may depend on context. If the address is part of an URL then 077 is invalid (see the definition of dec-octet in RFC 3986 section 3.2.2.)
John Davies <john.davies@philips.com> wrote:
If my address is 192.168.1.112 everything works If my address is 192.168.001.112 it doesn’t work and throws an exception about not finding the host.
It’s not a big deal, but it sure took me a long time to track down.
Is there some sort of Boost magic I can do to convert the bad address into a good address?
If you still need to remove leading zeroes from the address, consider using Boost.Regex (or stdlib regex if you have a C++11 toolset). The regular expression "\b0+(?=[1-9])" will match one or more leading zeroes that precede a non-zero digit. Replace each match with an empty string. |+| M a r k |+| Mark Stallard Business Application Services Global Business Services Information Technology Raytheon Company
Leading zeros in an IP octet indicate octal. If you ping 192.168.077.1 from both Linux and Windows you get
ping 192.168.077.1 PING 192.168.077.1 (192.168.63.1) 56(84) bytes of data.
Note how it converted 077 to 63. James On Thu, Feb 25, 2016 at 1:20 PM, Mark R Stallard <stallard@raytheon.com> wrote:
John Davies <john.davies@philips.com> wrote:
If my address is 192.168.1.112 everything works If my address is 192.168.001.112 it doesn’t work and throws an exception about not finding the host.
It’s not a big deal, but it sure took me a long time to track down.
Is there some sort of Boost magic I can do to convert the bad address into a good address?
If you still need to remove leading zeroes from the address, consider using Boost.Regex (or stdlib regex if you have a C++11 toolset).
The regular expression "\b0+(?=[1-9])" will match one or more leading zeroes that precede a non-zero digit. Replace each match with an empty string.
|+| M a r k |+|
*Mark Stallard* Business Application Services Global Business Services Information Technology * Raytheon Company*
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Leading zeros in an IP octet indicate octal.
If you ping 192.168.077.1 from both Linux and Windows you get
ping 192.168.077.1 PING 192.168.077.1 (192.168.63.1) 56(84) bytes of data.
Note how it converted 077 to 63. The problem seems to be is that apart from the name, there is nothing
On 25.02.2016 16:40, james wrote: that would guide the interpretation of the leading zeroes in dot-*decimal* notation for IPv4 addresses. For instance, while ping on my Mac agrees with the octal interpretation, nslookup doesn't::
192.168.077.1 Server: 192.168.3.1 Address: 192.168.3.1#53
Name: 192.168.077.1 Address: 192.168.77.1 Regardless, the ambiguity seems stronger than what I initially thought. Cheers, Leon
James
On Thu, Feb 25, 2016 at 1:20 PM, Mark R Stallard <stallard@raytheon.com <mailto:stallard@raytheon.com>> wrote:
John Davies <john.davies@philips.com <mailto:john.davies@philips.com>> wrote:
> If my address is 192.168.1.112 everything works > If my address is 192.168.001.112 it doesn’t work and throws an exception > about not finding the host. > > It’s not a big deal, but it sure took me a long time to track down. > > Is there some sort of Boost magic I can do to convert the bad address > into a good address?
If you still need to remove leading zeroes from the address, consider using Boost.Regex (or stdlib regex if you have a C++11 toolset).
The regular expression "\b0+(?=[1-9])" will match one or more leading zeroes that precede a non-zero digit. Replace each match with an empty string.
|+| M a r k |+|
*Mark Stallard* Business Application Services Global Business Services Information Technology* Raytheon Company*
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org <mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 26/02/2016 05:38, Leon Mlakar wrote:
Leading zeros in an IP octet indicate octal.
If you ping 192.168.077.1 from both Linux and Windows you get
ping 192.168.077.1 PING 192.168.077.1 (192.168.63.1) 56(84) bytes of data.
Note how it converted 077 to 63. The problem seems to be is that apart from the name, there is nothing
On 25.02.2016 16:40, james wrote: that would guide the interpretation of the leading zeroes in dot-*decimal* notation for IPv4 addresses. For instance, while ping on my Mac agrees with the octal interpretation, nslookup doesn't::
It's most likely just one of those things that nobody thought someone would ever do, so the behaviour comes down to the quirks of whatever text-to-number library function the program happened to use (eg. atoi, strtol, boost::lexical_cast, etc). Some of those will treat leading zeroes as octal and some won't.
participants (1)
-
Bjorn Reese -
Davies, John -
Gavin Lambert -
james -
Leon Mlakar -
Mark R Stallard