Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
pike
pike
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 109
    • Issues 109
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • pikelang
  • pikepike
  • Issues
  • #10033

Closed
Open
Created Apr 21, 2020 by Henrik (Grubba) Grubbström@grubbaMaintainer

Operator assignment and strict_types

From the Pike developers mailinglist:

22509896 2018-03-26 17:36 -0700 /41 lines/ Marc Simpson <marc@0branch.com>
Sender: SRS0+w18L=GR=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Imported: 2018-03-27 02:36 av Brevbäraren
External recipient: pike-devel@lists.lysator.liu.se
To: Pike (-) developers forum <20565>
Subject: Operator assignment and strict_types

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

Assignee
Assign to
Pike Next
Milestone
Pike Next
Assign milestone
Time tracking
None
Due date
None