in reply to Re: Re: Re: gethostbyname("1.1.1") returns 1.1.0.1 ????
in thread gethostbyname("1.1.1") returns 1.1.0.1 ????

I suppose you probably are misunderstanding me.

By "range", I mean the range of possible numeric values in each part. For example, in the typical "dotted quad" notation, the range of legal values in each part is 0 to 255, the possible values of an unsigned 8-bit number.

When there are only three parts, the first two are 8 bits in size (thus have the usual range 0-255), but the last part represents a 16-bit number, and thus can legally have any value in the range 0 - 65535. 127.1.54321 is a legal, valid IP address.

If you disagree with that, then you are simply mistaken. Try it:  inet_aton("127.1.54321");

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: gethostbyname("1.1.1") returns 1.1.0.1 ????
by MarkM (Curate) on Mar 12, 2003 at 04:51 UTC

    I did misunderstand you, and also, I was not aware of the behaviour that you are referencing.

    Do you have a solid reference (from an RFC, STD, FYI, ISO, or POSIX document?) that describes this addressing notation? I did quite a few searches myself, and other than a few manpages that describes 'this is how inet_aton works', and the source code for inet_aton in GLIBC describing the intended effect, I cannot find any reference on the Internet that describes this 'feature'. In fact, I find the opposite. RFC's regarding the use of addresses in an email address seem to require that each decimal integer be in the range 0-255 (although they also seem to require 4 integers).

    Netscape on Linux supports addresses such as http://192.1204551/ (aka http://192.18.97.71/ aka http://java.sun.com/). Internet Explorer under Windows does not. Are you certain that this feature is portable? Or was it a convenient notation that was merely introduced in one of the earlier BSD tracks, and has continued to exist until today? Until I can verify that this feature is standard and portable, I cannot agree with your correction. I would appreciate it if you could prove to me that I am wrong. I hate not knowing.

      addresses such as http://192.1204551/ (aka http://192.18.97.71/
      aka http://3222430023/.
      Do you have a solid reference...?
      Nope. I looked too, and couldn't find one.
      I agree with your assessment that it probably is not portable.
      (Leave it to Microsoft to write an incompatible - if compliant - network library...)

      jdporter
      The 6th Rule of Perl Club is -- There is no Rule #6.

      RFC0791
      Addresses are fixed length of four octets (32 bits). An address begins with a network number, followed by local address (called the "rest" field). There are three formats or classes of internet addresses: in class a, the high order bit is zero, the next 7 bits are the network, and the last 24 bits are the local address; in class b, the high order two bits are one-zero, the next 14 bits are the network and the last 16 bits are the local address; in class c, the high order three bits are one-one-zero, the next 21 bits are the network and the last 8 bits are the local address.
          Address Formats:
      
            High Order Bits   Format                           Class
            ---------------   -------------------------------  -----
                  0            7 bits of net, 24 bits of host    a
                  10          14 bits of net, 16 bits of host    b
                  110         21 bits of net,  8 bits of host    c
                  111         escape to extended addressing mode
      
            A value of zero in the network field means this network.  This is
            only used in certain ICMP messages.  The extended addressing mode
            is undefined.  Both of these features are reserved for future use.
      

      once you have grokked this your question will be answered.

        I do not consider this to be an answer. Class A, Class B, and Class C addresses are methods of assigning network numbers. They have nothing to do with the format of the 'dotted decimal' form. The above describes an allocation scheme, it does not describe a syntax for dotted decimal notation. The words "dotted decimal notation" appear nowhere in the text.

        To prove this to yourself, consider the wording of a Class C address: "21 bits of net, 8 bits of host". If this section was not speaking about an allocation scheme, and it was talking about the suggested decimal notation syntax, would it not be an indication that "a.b" should mean a=21bits, and b=8bits? Of course not. This section defines how the 32 bit address space is logically classified into different sized network partitions.

        Now, I can believe that the BSD people assumed that they could extend the traditional 'quad dotted decimal' form, and 'enhance' inet_aton/inet_addr to allow nodes within a Class A allocation to be addressed using a single integer, however, nowhere have I found an official syntax (BNF or otherwise) that defines this method of accepting/parsing dotted decimal ip addresses as a requirement, or even a suggestion. Also, as I stated before, the email specifications seem to require that ip addresses are strictly checked, and that ip addresses used in email headers must be in quad form with values of 0-255 for each decimal integer.

        The inet_aton/inet_addr implementation in GLIBC further extends 'decimal integer' form to allow base 8 and base 16 integers. I have not found a reference that defines this implementation as standard or portable either.