Hi folks,
It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents.
For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain:
int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types
Similarly, operator assignment on aggregates fails to elicit a warning:
array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]);
// no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]);
// warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]);
I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner.
Have there been any discussions around addressing this inconsistency?
Thanks, Marc
Looks like a bug to me. I think these should all give the same warnings.
Bumping the following message from 2018; just built the latest HEAD and this still seems to be an issue (assuming it's considered a bug).
Best, Marc
On Mon, Mar 26, 2018 at 5:36 PM Marc Simpson marc@0branch.com wrote:
Hi folks,
It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents.
For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain:
int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types
Similarly, operator assignment on aggregates fails to elicit a warning:
array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]); // no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]); // warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]);
I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner.
Have there been any discussions around addressing this inconsistency?
Thanks, Marc
Hi folks,
Hi Marc.
It took some time, but...
It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents.
Correct.
For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain:
int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types
Similarly, operator assignment on aggregates fails to elicit a warning:
[...]
Fixed in Pike devel.
The operator assignment expressions now warn in the same places as their corresponding explict syntax does.
The ++ and -- operators have not been modified (yet).
I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner.
Correct.
Have there been any discussions around addressing this inconsistency?
Now there has...
/grubba
pike-devel@lists.lysator.liu.se