Running fpc 3.0.4 on Fedora 30.

The StrToHostAddr function in the sockets unit accepts negative octets in the source ip address. Consider this program:

program ip4_neg;
{$mode objfpc}{$H+}
uses
   sockets;
var
   ip4_addr: in_addr;
begin
   ip4_addr := StrToHostAddr('172.-16.32.14');
   if ip4_addr.s_addr = 0 then
     writeln('invalid ip.')
   else
     writeln('ip is valid: ' + HostAddrToStr(ip4_addr));
end.

This program parses an invalid ip address. But when run:

$ ./ip4_neg
ip is valid: 172.240.32.14

This seems to me to be a bug. I tested this in Python using its socket.inet_aton (a wrapper around the C library function) and also directly in C and both returned an error for this address.

E.g,

$ python
Python 2.7.17 (default, Oct 21 2019, 17:20:57)
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>> import socket >> socket.inet_aton('172.-16.32.14')

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
socket.error: illegal IP address string passed to inet_aton

>>

This should indeed be ckecked.

Please report this in the bugtracker, so we don't forget to look at it!

Thank you!

Michael.

Hi,

I have already fixed it, with a simplistic fix, I think. Committed as SVN r44845.

Basically it was wrapping everything in the longint number range silently to a byte. So for example a string saying '172.300.32.14' was accepted as IP 172.44.32.14. My patch fixes this too, not just the negatives, but please feel free to verify, or improve on it if you feel like.

This was an ancient bug, the code in question was unchanged since SVN rev 1, so 2005 at least, but probably longer.

Charlie

Great, good to know it's fixed. Not having the SVN repo to hand, I can't tell how recent that revision is. Has this change made it to any released version of the compiler?

If it hasn't then I will have to either roll a custom function or look to falling back on the system native libc's inet_pton function.

Patch looks good indeed.

Thanks, Karoly.

Michael.

Hi,

No. I just fixed it yesterday. :) So the fix is new. I'll probably get it merged to the soon-to-be released 3.2, if no one objects.

If it hasn't then I will have to either roll a custom function or look to falling back on the system native libc's inet_pton function.

You can compile yourself a custom version of the sockets unit from current trunk too in the mean time. Or you can even patch 3.0.4, if you want. Here's what's changed:

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/rtl-extra/src/inc/sockets.inc?r1=44845&r2=44844&pathrev=44845

Falling back to inet_pton() is also an option indeed, if your program already links against libc (for threading or other reasons), that might be the easiest option.

Charlie

Oh I see. I thought you meant it had already been fixed before I raised it.

That's simple enough. I will probably just make a custom copy of that function for now and leave the sockets unit alone so that future compiler upgrades don't cause issues.

Falling back to inet_pton() is also an option indeed, if your program already links against libc (for threading or other reasons), that might be the easiest option.

It doesn't yet, and I generally try to avoid libc if I can, but the next part of my program has to parse IPv6 addresses and do CIDR calculations against them, and so I half suspect that I'm going to end up using libc anyway.

But that's a bridge to cross when I come to it. Thank you again for the blazingly fast bug fix.

Cheers,
Noel.

Op 2020-04-20 om 09:41 schreef Karoly Balogh (Charlie/SGR):

Done