On Sun, 17 May 2020, Noel Duffy via fpc-pascal wrote:
On 17/05/20 3:00 am, Michael Van Canneyt wrote:
On Sat, 16 May 2020, Michael Van Canneyt wrote:
On Sat, 16 May 2020, Jonas Maebe wrote:
On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
While doing some work on bug 37060, the refactoring of StrToHostAddr
and
StrToHostAddr6 in the sockets
unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
StrToHostAddr is doing no validation at all on input address characters
before calling the function Val, so any Pascal notation that Val
accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
and mathematical signs are all accepted in ipv4 octets.
I added a note to https://bugs.freepascal.org/view.php?id=37013 about
the fact that this test program fails if range checking is enabled (I
don't know if the range error is in StrToHostAddr6 or in the test
program itself).
I will check. I never use range checking, so that could have easily
escaped me.
Fixed 2 occurrences of a range check.
Looking at the code in SVN, I spotted a couple of still extant
references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's
possible to trigger range check errors for them. All s6_addr16s should
be u6_addr16s.
If you try parsing an address like '::ffff' it will hit this part of the
code.
Sorry for the screw-up. Normally I religiously use range checks in my
own code, but it completely went out of my head when working on this.
That's what you get when communication with someone who doesn't use them:
It's contagious ;-)
I'll have a look.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
