Warnint util 4516 v4

[catenacyber]

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

Describe changes:

• Fix integer warnings -Wimplicit-int-conversion in all files

Extends #6792 : complete with CI check...

Replaces #6807 with completion for all files

Thoughts about the commit history ?
This PR can be split into smaller PRs as some points need a careful review (detect-content.c for instance)

[codecov]

Codecov Report

Merging #6820 (cdf5b7d) into master (23fb139) will decrease coverage by 0.27%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##           master    #6820      +/-   ##
==========================================
- Coverage   77.66%   77.39%   -0.28%     
==========================================
  Files         620      620              
  Lines      187159   187149      -10     
==========================================
- Hits       145365   144851     -514     
- Misses      41794    42298     +504     

Flag	Coverage Δ
fuzzcorpus	57.71% <58.79%> (-0.16%)	⬇️
suricata-verify	52.45% <60.42%> (-0.86%)	⬇️
unittests	62.87% <68.52%> (-0.01%)	⬇️

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

[suricata-qa]

Information:

field	test	baseline	%
	tlpr1_stats_chk
.flow.memuse	534901888	505591168	105.8%

Pipeline 5805

[victorjulien]

@jasonish any thoughts here? IIRC this func was introduced by you?

[catenacyber]

This is an easy one, without knowing the function's purpose
l = l & 65535; return l; does the same thing as return (uint16_t)l; (right ?)

[victorjulien]

I guess I'm not actually sure what C is doing (and/or expected to do here), esp since this code IIRC comes from OpenBSD. They seem to know a thing or 2 about this stuff.

[jasonish]

l = l & 65535; return l; does the same thing as return (uint16_t)l; (right ?)

A quick test shows that they do the same thing, but its not nearly as clear to me as the original form.

[catenacyber]

Do you prefer l = l & 65535; (uint16_t)return l; ? (even if it is redundant)

[jasonish]

I think so, at least its clear.. Would this work as well?

return (uint16_t)(l & 65535);

[catenacyber]

ok for me

[catenacyber]

Any thoughts on the CIFuzz find ?
Should we apply this patch ?

diff --git a/src/defrag.h b/src/defrag.h
index 771616e4d..9c8e6f1d8 100644
--- a/src/defrag.h
+++ b/src/defrag.h
@@ -45,7 +45,7 @@ typedef struct Frag_ {
     uint16_t offset;            /**< The offset of this fragment, already
                                  *   multiplied by 8. */
 
-    uint16_t len;               /**< The length of this fragment. */
+    uint32_t len;               /**< The length of this fragment. */

[victorjulien]

Any thoughts on the CIFuzz find ? Should we apply this patch ?

diff --git a/src/defrag.h b/src/defrag.h
index 771616e4d..9c8e6f1d8 100644
--- a/src/defrag.h
+++ b/src/defrag.h
@@ -45,7 +45,7 @@ typedef struct Frag_ {
     uint16_t offset;            /**< The offset of this fragment, already
                                  *   multiplied by 8. */
 
-    uint16_t len;               /**< The length of this fragment. */
+    uint32_t len;               /**< The length of this fragment. */

Can you do a PR with this so we can review it properly? I think adding new patch suggestions in PR comments isn't very effective for review/discussion.

[catenacyber]

Can you do a PR with this so we can review it properly? I think adding new patch suggestions in PR comments isn't very effective for review/discussion.

Done in #7006

But I was rather under the impression that we should split this big PR into smaller PRs...

[victorjulien]

Can you do a PR with this so we can review it properly? I think adding new patch suggestions in PR comments isn't very effective for review/discussion.

Done in #7006

But I was rather under the impression that we should split this big PR into smaller PRs...

Sure you can split PRs or do PRs for smaller changes, right? Suggesting code changes in comments instead of a PR just seems to be an anti-pattern when the PR is to review code changes in git.