We're using inet_pton(), so we don't need to worry about non-dotted-quad addresses.

inet_pton(), and thus ws_inet_pton(), won't accept hex or
fewer-than-four-component IPv4 addresses, at least on Single UNIX
Specification-compliant systems - the SUSv4 explicitly says

	The inet_pton() function does not accept other formats (such as
	the octal numbers, hexadecimal numbers, and fewer than four
	numbers that inet_addr() accepts).

so we don't need to check for "inet_atons that accept strings such as -
"130.230" as valid addresses".

That also means that, "if there are any places where this needs to
support the hex-address form for IPv4 addresses, or to support fewer
than 4 components for a network address", those places were hosed even
before we stopped using inet_aton(), so there are presumably no such
places.  (Itojun's comment was probably just an expression of general
concern, rather than a note of a known problem.)

Change-Id: Id16b6ebd3550dc3bf5a0fc283898a99b7abc163c
Reviewed-on: https://code.wireshark.org/review/24057
Reviewed-by: Guy Harris <guy@alum.mit.edu>

0 files changed, 0 insertions, 0 deletions