Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • xserver xserver
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 941
    • Issues 941
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 124
    • Merge requests 124
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • xorgxorg
  • xserverxserver
  • Merge requests
  • !190
The source project of this merge request has been removed.

Separate each "assert(a && b)" statement into "assert(a)" and "assert(b)" for more precise diagnostics.

Merged Adam Richter requested to merge (removed):master into master May 02, 2019
  • Overview 2
  • Pipelines 0
  • Changes 11

Separate each statement of the form "assert(a && b);" into "assert(a);" and "assert(b);" for more precise diagnostics, except for this clever use in drmmode_display.c where it was used to pass a hint to developers:

assert(num_infos <= 32 && "update return type");

The following potential advantages come to mind:

  1. Assertion failure are often sporadic and users who report them may not be in a position to narrow them down further easily, so it is important to get as much precision from each assertion failure as possible.

  2. It's often more readable, sometimes eliminating parentheses.

  3. When using a debugger to step over an assertion failure in the first part of the statement, the second part is still tested.

  4. Providing separate branch likelihood hints to the compiler in the form of separate assert statements does not require the compiler to be quite as smart to recognize that it should optimize both branches, although I do not know if that makes a difference for any compiler commonly used to compile X (that is, I suspect that they are all smart enough to realize is that "a && b" is likely true, then "a" is likely true and "b" is likely true).

I have confirmed that the resulting tree built without any apparent complaints about the assert statements, and I am running the resulting X server now.

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: master