[fpc-pascal] StrToHostAddr in sockets unit accepts negative octets

Noel Duffy noelduffy at xtra.co.nz
Mon Apr 20 11:29:56 CEST 2020


On 20/04/20 7:41 pm, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
> 
> On Mon, 20 Apr 2020, Noel Duffy via fpc-pascal wrote:
> 
>>> I have already fixed it, with a simplistic fix, I think. Committed as
>>> SVN r44845.
>>>
>> 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?
> 
> 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.

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

> 
>> 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

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.



More information about the fpc-pascal mailing list