Question about inet_aton and inet_addr function. - Linux

This is a discussion on Question about inet_aton and inet_addr function. - Linux ; Hello All! I've written a simple example that demonstrates the problem. Please look at code below: ////////////////////////////////////////////////////////////////////////////////////////////////////////////////// #include #include #include #include #include int main(int argc, char** argv) { if(argc { fprintf(stderr, "Usage: %s \n", argv[0]); exit(-1); } struct in_addr net_addr; ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Question about inet_aton and inet_addr function.

  1. Question about inet_aton and inet_addr function.

    Hello All!

    I've written a simple example that demonstrates the problem.
    Please look at code below:

    //////////////////////////////////////////////////////////////////////////////////////////////////////////////////
    #include
    #include
    #include

    #include
    #include

    int main(int argc, char** argv)
    {
    if(argc < 2)
    {
    fprintf(stderr, "Usage: %s \n", argv[0]);
    exit(-1);
    }

    struct in_addr net_addr;
    if(inet_aton(argv[1], &net_addr))
    {
    printf("Correct address (%s)!\n",inet_ntoa(net_addr));
    }
    else
    {
    printf("Inorrect address!\n");
    }

    return 0;
    }
    //////////////////////////////////////////////////////////////////////////////////////////////////////////////////

    The example should be clear

    Please look at results:

    krivenok@develop 15:28:56 ~/work/inet_addr $ ./a.out "127.0.0.1"
    Correct address (127.0.0.1)!
    krivenok@develop 15:29:42 ~/work/inet_addr $ ./a.out "127.1024"
    Correct address (127.0.4.0)!
    krivenok@develop 15:29:51 ~/work/inet_addr $ ./a.out "130.10.512"
    Correct address (130.10.2.0)!
    krivenok@develop 15:30:25 ~/work/inet_addr $ ./a.out "130.10.513"
    Correct address (130.10.2.1)!
    krivenok@develop 15:30:29 ~/work/inet_addr $ ./a.out "aaa"
    Inorrect address!
    krivenok@develop 15:30:46 ~/work/inet_addr $ ./a.out "127.0.0.256"
    Inorrect address!
    krivenok@develop 15:30:55 ~/work/inet_addr $

    It seems that all right.

    But wait...
    Look at this:

    krivenok@develop 15:30:55 ~/work/inet_addr $ ./a.out "127.0.0.1 "
    Correct address (127.0.0.1)!
    krivenok@develop 15:33:22 ~/work/inet_addr $ ./a.out "127.0.0.1 some
    characters"
    Correct address (127.0.0.1)!
    krivenok@develop 15:33:39 ~/work/inet_addr $ ./a.out "127.0.0.1 what
    the hell is going on here?"
    Correct address (127.0.0.1)!
    krivenok@develop 15:34:24 ~/work/inet_addr $

    I've searched through glibc-2.6 sources and found that space character
    is a valid separator (along with '\0')!!!
    All characters after space are simply ignored.

    Is this behaviour correct?

    I also found that POSIX doesn't specify inet_aton function.
    However, it specifies inet_addr function, which calls (at least in
    glibc-2.6) inet_aton
    and wraps return value.

    POSIX says about inet_addr:
    The inet_addr() function shall convert the string pointed to by cp, in
    the
    standard IPv4 dotted decimal notation, to an integer value suitable
    for
    use as an Internet address.

    That is POSIX says nothing about space separator!!!
    Why glibc considers space as a valid separator?

    Thank you beforehand!

  2. Re: Question about inet_aton and inet_addr function.

    On Tue, 4 Dec 2007 04:44:47 -0800 (PST) Krivenok Dmitry wrote:

    | I've searched through glibc-2.6 sources and found that space character
    | is a valid separator (along with '\0')!!!
    | All characters after space are simply ignored.
    |
    | Is this behaviour correct?

    The proper question to ask with respect to POSIX is if it is compliant
    behaviour.


    | I also found that POSIX doesn't specify inet_aton function.
    | However, it specifies inet_addr function, which calls (at least in
    | glibc-2.6) inet_aton
    | and wraps return value.
    |
    | POSIX says about inet_addr:
    | The inet_addr() function shall convert the string pointed to by cp, in
    | the
    | standard IPv4 dotted decimal notation, to an integer value suitable
    | for
    | use as an Internet address.
    |
    | That is POSIX says nothing about space separator!!!

    Hence it is unspecified behaviour. Implementations could choose any
    number of behaviours and be compliant.


    | Why glibc considers space as a valid separator?

    Because the developers wanted to. I can see the convenience. I wish it
    also did this for the tab character. Or why not the whole control range
    plus space:

    if ( (unsigned int) c <= 32U ) /* stop the parsing here */ ...


    | Thank you beforehand!

    I think I'd rather have a function that parses an IP address or host name
    in such a way that if it reaches a point where the parsing would be invalid
    while everything parsed up to that point can be considered complete, then
    it should have a means to pass a pointer to that point to the caller, much
    like the strtol(), strtoul(), strtoll(), strtoull(), strtod(), and strtold()
    functions. Then I could easily parse through a list of comma separated IP
    addresses, or whatever, without having to piece it together with a separate
    call to something to split the string before parsing the addresses.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-12-04-1129@ipal.net |
    |------------------------------------/-------------------------------------|

  3. Re: Question about inet_aton and inet_addr function.

    Krivenok Dmitry wrote:
    >...
    > struct in_addr net_addr;
    > if(inet_aton(argv[1], &net_addr))
    >...
    >krivenok@develop 15:33:22 ~/work/inet_addr $ ./a.out "127.0.0.1 some
    >characters"
    >Correct address (127.0.0.1)!


    In short, because inet_aton is a conversion function, not a validation
    function.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.

  4. Question about inet_aton and inet_addr function.

    TR> In short, because inet_aton is a conversion function,
    TR> not a validation function.

    It seems pointless to separate the two ideas. Any validation function
    that operated correctly would have to actually construct the IP
    address, in order to detect strings that were invalid addresses
    because of integer overflow. As M. Howard said, a function that
    converts the string and returns a pointer to the next unconverted
    character is far more useful. I wrote one of my own several years
    ago, and use it in all of my programs that deal with human-readable IP
    addresses.

  5. Re: Question about inet_aton and inet_addr function.

    On Fri, 7 Dec 2007 03:02:11 -0800 (PST) J de Boyne Pollard wrote:

    | TR> In short, because inet_aton is a conversion function,
    | TR> not a validation function.
    |
    | It seems pointless to separate the two ideas. Any validation function
    | that operated correctly would have to actually construct the IP
    | address, in order to detect strings that were invalid addresses
    | because of integer overflow. As M. Howard said, a function that
    | converts the string and returns a pointer to the next unconverted
    | character is far more useful. I wrote one of my own several years
    | ago, and use it in all of my programs that deal with human-readable IP
    | addresses.

    Maybe it would be useful to hae a function that allowed a list of characters
    that would be considered non-error separators. If the list is empty or a
    NULL pointer used in its place, no separators would be allowed and the whole
    string must be a complete IP address. Either way, validation would then be
    applied to the extend appropriate. Obviously "192.168.256.1" should fail.
    If I were to write such a function I'd also contemplate whether octal should
    be considered a valid conversion. E.g. should "192.168.012.023" be the same
    as "192.168.12.23" or "192.168.10.19" or be treated as not well formed?
    Some might consider octal to be permitted only when used for all parts of
    the address. There could potentially be reasons to go down any of these
    decision paths in some unanticipated application. This and other issues,
    such as how to handle IPv4-in-IPv6, network ranges, etc., could make for a
    rather complicated conversion tool. But it would be flexible.

    I've been contemplating more address conversion tools for LIBH. It now has
    a few that do things like convert IPv4 addresses and networks. But it does
    need some IPv6 support. Would there ever be a reason to support any other
    coding besides hexadecimal in IPv6 addresses, aside from the form where an
    IPv4 address is appended? It would be hard to syntactically discriminate
    them since hexadecimal is the default and allows a leading 0 for IPv6.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-12-08-1157@ipal.net |
    |------------------------------------/-------------------------------------|

  6. Question about inet_aton and inet_addr function.

    p> Would there ever be a reason to support any other coding besides
    p> hexadecimal in IPv6 addresses, aside from the form where an
    p> IPv4 address is appended?

    I've never encountered a need to support any other base.

+ Reply to Thread