Use size_t for Process offset values

[Explorer09]

Convert cmdlineBasenameStart, cmdlineBasenameEnd and procExeBasenameOffset values in Process to size_t type. Improve functions that search for "basenames", "comm" and "procExe" to use size_t for offsets as well.

I made these set of code changes before the length properties of RichString object can be upgraded to size_t.

Note: This PR contains many platform specific code changes. I didn't test all of them. It is possible that I broke something.

[Explorer09]

Side note: I have no idea why this conditional needs a lastSlash != exe. I thought it should be legitimate when lastSlash == exe, that is, when the exe string begins with a slash such as "/vmlinuz".

[Explorer09]

Well, it looks like the changes to size_t do create an undefined behavior.

The commStart and commEnd variables in Process_makeCommandStr(), they can become negative during the stripExeFromCmdline code path.

I think the logic there needs to be revised. While I could workaround by using ssize_t for commStart and commEnd, that doesn't look like a long term solution.

I would try to make a commit that properly fixes that.

EDIT: This change has been done.

[BenBE]

FYI; the last time I needed to work on this logic, it took me the better of 3 months to track down some issue with the command line handling in this code. So be careful with your changes; the details are important with this part of the code …

[Explorer09]

@BenBE
The changes of upgrading the length values of RichString to size_t is ready here:
https://github.com/Explorer09/htop-1/commits/rich-string-chlen/

But I'm not sure I should file a new PR for it or just merge with this one. The new changes depend on this PR and I've seen you added tags and categories to this PR already.

[BenBE]

@Explorer09 Make a second PR as this makes discussing the changes easier. From a quick view at your commits on that branch I already noticed some things I'd like to change with that patchset …

[BenBE]

Will take me some time to check consistency with all those edits. Especially with all the changes regarding edge cases re signed-nes changing due to this PR.

What might be worth doing is having the markers for "not used" become a special constant #define STRPOS_UNUSED ((size_t)-1).

[Copilot]

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

Process.c:136

• Potential underflow in matchCmdlinePrefixWithExeSuffix: if cmdlineBaseOffset is 0, subtracting 1 may underflow. Consider adding a guard check to ensure cmdlineBaseOffset is non-zero before subtracting.

for (i = cmdlineBaseOffset - 1, j = exeBaseOffset - 1; i != (size_t)-1 && j != (size_t)-1 && cmdline[i] == exe[j]; --i, --j)

[BenBE]

A quick glance at the indicated code location confirms this underflow to be reached. The handling seems to be fine, but a cleaner solution would be to properly catch this before reaching that for loop.

[Explorer09]

A quick glance at the indicated code location confirms this underflow to be reached. The handling seems to be fine, but a cleaner solution would be to properly catch this before reaching that for loop.

It's already done, but in the last commit only ("Process: Use size_t for "cmdline" and "procExe" offsets"). Should I move that change to an earlier commit to silence the AI complaint?

[BenBE]

The AI complaint is about the cmdlineBaseOffset - 1 and exeBaseOffset - 1, but the first one in particular. When you enter with cmdlineBaseOffset set to 0, this underflows and is what the AI remarked about. Yes, that's defined in the standard and the code handles this situation, but a somewhat cleaner code path here would be nice.

Ideally, your last commit would only have to update the type, with all preceding ones ensuring no negative numbers appear along the modified code paths.

[Explorer09]

The AI complaint is about the cmdlineBaseOffset - 1 and exeBaseOffset - 1, but the first one in particular. When you enter with cmdlineBaseOffset set to 0, this underflows and is what the AI remarked about. Yes, that's defined in the standard and the code handles this situation, but a somewhat cleaner code path here would be nice.

Ideally, your last commit would only have to update the type, with all preceding ones ensuring no negative numbers appear along the modified code paths.

I replied here. In short, maybe it helps by incrementing the i and j counters by 1.

            for (size_t i = cmdlineBaseOffset, j = exeBaseOffset;
               i != 0 && j != 0 && cmdline[i - 1] == exe[j - 1];
               --i, --j)
               /* empty loop body */;
            if (i == 0 && j != 0 && exe[j - 1] == '/') {
               *cmdlineBasenameStart = cmdlineBaseOffset;
               return matchLen;
            }