[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