Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

detect-engine-address-ipv4: convert unittests to FAIL/PASS APIs #11873

Conversation

AkakiAlice
Copy link
Contributor

Ticket #6318

Make sure these boxes are checked accordingly before submitting your Pull Request -- thank you.

Contribution style:

Our Contribution agreements:

Changes (if applicable):

Link to ticket: https://redmine.openinfosecfoundation.org/issues/6318

Describe changes:

  • Update detect-engine-address-ipv4.c unittests to use FAIL/PASS API

Provide values to any of the below to override the defaults.

  • To use an LibHTP, Suricata-Verify or Suricata-Update pull request,
    link to the pull request in the respective _BRANCH variable.
  • Leave unused overrides blank or remove.

SV_REPO=
SV_BRANCH=
SU_REPO=
SU_BRANCH=
LIBHTP_REPO=
LIBHTP_BRANCH=

Copy link

codecov bot commented Oct 3, 2024

Codecov Report

Attention: Patch coverage is 70.00000% with 18 lines in your changes missing coverage. Please review.

Project coverage is 82.57%. Comparing base (45eb7e4) to head (9a6a793).
Report is 12 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11873      +/-   ##
==========================================
- Coverage   82.60%   82.57%   -0.03%     
==========================================
  Files         912      912              
  Lines      249351   249347       -4     
==========================================
- Hits       205965   205908      -57     
- Misses      43386    43439      +53     
Flag Coverage Δ
fuzzcorpus 60.46% <ø> (-0.14%) ⬇️
livemode 18.72% <ø> (-0.01%) ⬇️
pcap 44.08% <ø> (+0.01%) ⬆️
suricata-verify 62.02% <ø> (-0.02%) ⬇️
unittests 58.94% <70.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi there, we're on the right path, but some more work to be done, to be fully compliant with the work required for this FAIL/PASS API conversion.

Please read my inline comment, I think it will help with all other cases present here, too. The parent ticket for this task my offer more insight and background into this work, if you want: https://redmine.openinfosecfoundation.org/issues/2975

For the commit message title, it's too long, you could shorten it, while still preserving meaning, like so:
detect/address: convert ipv4 unittests to FAIL/PASS

Comment on lines 850 to +853
error:
DetectAddressFree(a);
DetectAddressFree(b);
return 0;
FAIL;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, all the lines that do something and then use a goto error are a FAIL case, and should be converted to a FAIL_IF format.

One of the goals for the FAIL/PASS API conversion is to remove all branching logic (the if checks) in unit tests, too.

So let's try to clean up this test (and others in this file if they follow a similar patter), so that we first have all FAIL possibilities, and, if nothing has failed, we will then have the calls to Free functions, to avoid memory leaks on PASS, and finish the test with a PASS.

This will further improve readability, and also allow us to get rid of the result variable, since we will be explicitly failing for each check case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thank you so much for clarifying! I was feared it could cause unwanted memory leaks by not freeing the variables in case the test fails, I don't need to worry with that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, we only have to avoid memory leaks in the PASS scenario :)

@AkakiAlice AkakiAlice closed this Oct 3, 2024
@jufajardini jufajardini added the outreachy Contributions made by Outreachy applicants label Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
outreachy Contributions made by Outreachy applicants
Development

Successfully merging this pull request may close these issues.

2 participants