It doesn't "fail," it just passes them in a BSD way. See: http://tools.ietf.org/html/draft-main-ipaddr-text-rep-02
```
Meanwhile, a very popular implementation of IP networking went off in
   its own direction.  4.2BSD introduced a function inet_aton(), whose
   job was to interpret character strings as IP addresses.  It
   interpreted both of the syntaxes mentioned in [MTP] (see above): a
   single number giving the entire 32-bit address, and dot-separated
   octet values.  It also interpreted two intermediate syntaxes: octet-
   dot-octet-dot-16bits, intended for class B addresses, and octet-
   dot-24bits, intended for class A addresses.  It also allowed some
   flexibility in how the individual numeric parts were specified: it
   allowed octal and hexadecimal in addition to decimal, distinguishing
   these radices by using the C language syntax involving a prefix "0"
   or "0x", and allowed the numbers to be arbitrarily long.

The 4.2BSD inet_aton() has been widely copied and imitated, and so is
   a de facto standard for the textual representation of IPv4 addresses.
   Nevertheless, these alternative syntaxes have now fallen out of use
   (if they ever had significant use).  The only practical use that they
   now see is for deliberate obfuscation of addresses: giving an IPv4
   address as a single 32-bit decimal number is favoured among people
   wishing to conceal the true location that is encoded in a URL.  All
   the forms except for decimal octets are seen as non-standard (despite
   being quite widely interoperable) and undesirable.
```

So 34 is 0.0.0.34, or sometimes 34.0.0.0, 34.98 is 34.0.0.98, 34.98.23 is 34.98.0.23, and the space-delimited "blah" is obviously not part of the IP address so it's 1.2.3.4. The BSD code was desperate to give you an IP address regardless of the input format.