openwall / openwall/john

Autoconf: Review all inline test code

Open
#4,599 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement maintenance/cleanup
Dominant language
C
Stars
13.6k
Forks
2.6k
PR merge metrics
No merged PRs in 30d

Description

The inlined test sources in m4/jtr_arm_logic.m4 and similar files (there's two or three more) should be reviewed.

Example:

#include <arm_neon.h>
#include <stdio.h>

extern void exit(int);

int main() {
    uint32x4_t t;
    *((long*)&t) = 1;
    t = veorq_u32(t, t);
    if ((*(unsigned*)&t) == 88)
        printf(".");
    exit(0);
}

This particular one tests if we have veorq_u32().

What it really does is look for build fail or good exit code (vs. segfault): The "88" is only there to ensure things aren't optimized away, it doesn't test correctness.

All such programs should be trivially rewritten so we:

  • Get rid of aliasing violations.
  • Do a test that actually tests the correctness (it's not very important but just because we can).
  • Instead of the printf, exit with the calculated value (expected 0) or based on it (0 for good, 1 for bad).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the inline test source in m4/jtr_arm_logic.m4, then locate the two or three similar files mentioned in the issue. Review each program for aliasing violations and whether it checks the intrinsic's result rather than only build success or a non-optimized execution. Done means every such test uses a correctness-based exit status and no longer relies on the described printf or invalid aliasing.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
build-system
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.