[fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
Using fpc 3.0.4 on Fedora 30.
I've just started using the StrToHostAddr6 function in the sockets unit
to parse IPv6 addresses. I've found a couple of issues with it.
1. Even if address parsing fails, StrToHostAddr6 doesn't return an
all-zero result in the in6_addr return value. The documentation states
that it does, but my tests show it doesn't.
This can be trivially demonstrated with a program like so:
program ip6bug;
uses
SysUtils, sockets;
procedure parse_print_ip6(addr: String);
var
ip6: in6_addr;
idx: Cardinal;
begin
ip6 := StrToHostAddr6(addr);
write('"' + addr+'" ' + '-> ');
for idx := 0 to 15 do
write(IntToHex(byte(ip6.s6_addr8[idx]),2)+'-');
writeln();
end;
const
addr = 'fxg%::906e:9d2f:a520:4172';
begin
parse_print_ip6(addr);
end.
On my machine this produces:
"fxg%::906e:9d2f:a520:4172" ->
00-00-00-60-68-74-E0-00-00-00-00-61-4F-2B-60-00-
The problem is that the StrToHostAddr6 function doesn't set its return
value until the end of the function. If a parse error occurs
mid-function, it zeroes the record in which it's writing the result but
exits without setting the function return value. What gets returned
depends on what's on the stack.
I could have sworn that fpc would detect a function exiting without
setting a return value, but clearly 3.0.4 doesn't.
2. The second problem is that a colon-separated string containing
hexadecimal values of any length will be parsed and treated as valid by
StrToHostAddr6. E.g, it will parse a string like
"fe80ca2f1::906e:9d2f:a520:4172". The sample program produces this
output for this string:
"fe80ca2f1::906e:9d2f:a520:4172" ->
A2-F1-00-00-00-00-00-00-90-6E-9D-2F-A5-20-41-72-
For the part before the first colon, it has discarded all but the last
two bytes, A2 and F1. But it should not have accepted this string at
all. There can be only four characters between the colons.
Neither of these are difficult to fix. But I am curious to know why the
compiler lets a function return without setting a return value and
doesn't at least issue a warning. I know it does in some cases, because
I've often seen the message "Function result doesn't appear to be set".
But maybe that's only if you never set the result, as opposed to setting
it only for some paths through the code.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
On Sun, 3 May 2020, Noel Duffy via fpc-pascal wrote: Using fpc 3.0.4 on Fedora 30. I've just started using the StrToHostAddr6 function in the sockets unit to parse IPv6 addresses. I've found a couple of issues with it. 1. Even if address parsing fails, StrToHostAddr6 doesn't return an all-zero result in the in6_addr return value. The documentation states that it does, but my tests show it doesn't. I fixed that. The problem is that the StrToHostAddr6 function doesn't set its return value until the end of the function. If a parse error occurs mid-function, it zeroes the record in which it's writing the result but exits without setting the function return value. What gets returned depends on what's on the stack. I could have sworn that fpc would detect a function exiting without setting a return value, but clearly 3.0.4 doesn't. It checks if the result is assigned. This is done; But it does not check this for every exit, as far as I know it never has. 2. The second problem is that a colon-separated string containing hexadecimal values of any length will be parsed and treated as valid by StrToHostAddr6. E.g, it will parse a string like "fe80ca2f1::906e:9d2f:a520:4172". The sample program produces this output for this string: "fe80ca2f1::906e:9d2f:a520:4172" -> A2-F1-00-00-00-00-00-00-90-6E-9D-2F-A5-20-41-72- For the part before the first colon, it has discarded all but the last two bytes, A2 and F1. But it should not have accepted this string at all. There can be only four characters between the colons. If you send a patch for this, I'll apply it. Neither of these are difficult to fix. But I am curious to know why the compiler lets a function return without setting a return value and doesn't at least issue a warning. I know it does in some cases, because I've often seen the message "Function result doesn't appear to be set". But maybe that's only if you never set the result, as opposed to setting it only for some paths through the code. Exactly. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Concat TCollection?
I have many TCollection's that I need to concat together into one larger collection for streaming. Since it's just a list I thought I could add the elements together but it appears TCollection requires that it allocate each item. Is there a way to do this without relocating each item of the collection? There could be 1+ items so it's important that I reuse the existing collections. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concat TCollection?
On Sun, 3 May 2020, Ryan Joseph via fpc-pascal wrote: I have many TCollection's that I need to concat together into one larger collection for streaming. Since it's just a list I thought I could add the elements together but it appears TCollection requires that it allocate each item. Is there a way to do this without relocating each item of the collection? There could be 1+ items so it's important that I reuse the existing collections. Just set the Collection property of the items to the concatenated collection instance. Note that this effectively moves the items. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concat TCollection?
> On May 3, 2020, at 4:04 PM, Michael Van Canneyt > wrote: > > Just set the Collection property of the items to the concatenated collection > instance. > > Note that this effectively moves the items. That means I'll need to set it back later right? The original lists are being kept alive because they may need to be streamed also. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Concat TCollection?
On Sun, 3 May 2020, Ryan Joseph via fpc-pascal wrote: On May 3, 2020, at 4:04 PM, Michael Van Canneyt wrote: Just set the Collection property of the items to the concatenated collection instance. Note that this effectively moves the items. That means I'll need to set it back later right? The original lists are being kept alive because they may need to be streamed also. If you want to reuse the original collections: Yes. A collection item belongs only to 1 collection. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
On Sun, 3 May 2020 09:57:46 +0200 (CEST) Michael Van Canneyt wrote: On Sun, 3 May 2020, Noel Duffy via fpc-pascal wrote: The problem is that the StrToHostAddr6 function doesn't set its return value until the end of the function. If a parse error occurs mid-function, it zeroes the record in which it's writing the result but exits without setting the function return value. What gets returned depends on what's on the stack. I could have sworn that fpc would detect a function exiting without setting a return value, but clearly 3.0.4 doesn't. It checks if the result is assigned. This is done; But it does not check this for every exit, as far as I know it never has. That seems like it would be a valuable feature to have. I am not certain what's contained in an uninitialized variable that gets returned from a function but I'd guess there's a risk of information leakage. The way return values from functions get set is one part of the Pascal language I dislike. 2. The second problem is that a colon-separated string containing hexadecimal values of any length will be parsed and treated as valid by StrToHostAddr6. E.g, it will parse a string like "fe80ca2f1::906e:9d2f:a520:4172". The sample program produces this output for this string: "fe80ca2f1::906e:9d2f:a520:4172" -> A2-F1-00-00-00-00-00-00-90-6E-9D-2F-A5-20-41-72- For the part before the first colon, it has discarded all but the last two bytes, A2 and F1. But it should not have accepted this string at all. There can be only four characters between the colons. If you send a patch for this, I'll apply it. Sure I can take a stab at this. Do you normally get people to open a bug against which to post the patch? I'm not at all familiar with contributing to fpc, I'm afraid, so please bear with me! Also, if there's information on unit testing for library functions and procedures, that would be very helpful. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
On Sun, 3 May 2020, Noel Duffy via fpc-pascal wrote: On Sun, 3 May 2020 09:57:46 +0200 (CEST) Michael Van Canneyt wrote: On Sun, 3 May 2020, Noel Duffy via fpc-pascal wrote: The problem is that the StrToHostAddr6 function doesn't set its return value until the end of the function. If a parse error occurs mid-function, it zeroes the record in which it's writing the result but exits without setting the function return value. What gets returned depends on what's on the stack. I could have sworn that fpc would detect a function exiting without setting a return value, but clearly 3.0.4 doesn't. It checks if the result is assigned. This is done; But it does not check this for every exit, as far as I know it never has. That seems like it would be a valuable feature to have. I am not certain what's contained in an uninitialized variable that gets returned from a function but I'd guess there's a risk of information leakage. That's why the compiler warns about use of uninitialized variables. But there will always be corner cases the compiler does not catch. For the part before the first colon, it has discarded all but the last two bytes, A2 and F1. But it should not have accepted this string at all. There can be only four characters between the colons. If you send a patch for this, I'll apply it. Sure I can take a stab at this. Do you normally get people to open a bug against which to post the patch? I'm not at all familiar with contributing to fpc, I'm afraid, so please bear with me! Also, if there's information on unit testing for library functions and procedures, that would be very helpful. Yes, please open a bug report. If you attach a small console test program that demonstrates the bug (and subsequently the fix) then I will make sure it ends up in the correct place. If you make sure it exits with exit code 0 if all is well, and a nonzero exit code if there is an error, that will save me some work. If you post the URL for the bug here, I will look at it at once. Thanks for pointing it out! Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit
On 3/05/20 10:28 pm, Michael Van Canneyt wrote: Yes, please open a bug report. If you attach a small console test program that demonstrates the bug (and subsequently the fix) then I will make sure it ends up in the correct place. If you make sure it exits with exit code 0 if all is well, and a nonzero exit code if there is an error, that will save me some work. If you post the URL for the bug here, I will look at it at once. Done. Bug #37013. https://bugs.freepascal.org/view.php?id=37013 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Name collisions in scoped enums
I've been using scoped enums and noticed that I'm getting collisions with
reserved keywords. Shouldn't these be allowed in scoped enums since they are
required to be referenced using their type name as a prefix?
{$mode objfpc}
program test;
{$scopedenums on}
// error: Syntax error, "identifier" expected but "FILE" found
type
TSet = set of ( File, Array );
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
Am 04.05.2020 um 05:06 schrieb Ryan Joseph via fpc-pascal: I've been using scoped enums and noticed that I'm getting collisions with reserved keywords. Shouldn't these be allowed in scoped enums since they are required to be referenced using their type name as a prefix? No, keywords have a higher priority than identifiers, their context doesn't matter (e.g. you can't have a method named "File" either though one could apply the same reasoning here). If you want to use keywords you have to escape them using "&". Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Empty Set in constants in generics
Should generics accept empty sets as constants? I think they should and this is
a bug but I wanted to ask first.
{$mode objfpc}
program test;
type
TItem = (A, B, C);
TItems = set of TItem;
generic GType = class
end;
const
TOtherItems = []; // no problems here
type
// error: Incompatible types: got "Empty Set" expected "TItems"
TType = specialize GType<[]>;
begin
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
