Fix truncated fd numbers in -F field output

[kurok]

Summary

• Fix fd numbers >= 10000 being truncated in -F (field) output mode
• In the -F output path, numeric fd values are now printed directly via printf("%d") instead of going through fd_to_string(), which truncates to fit the fixed-width FDLEN buffer

Fixes #311

Details

fd_to_string() formats fd numbers into a buffer of size FDLEN (8 bytes). For fd numbers >= 10000, it truncates them with a * prefix (e.g., 12345 → *345). This is appropriate for the fixed-width tabular FD column, but incorrect for -F output which is designed for machine parsing.

Before:

$ bash -c 'ulimit -n 20000; exec 12345<> /dev/null; lsof -w -F fd -ap "$$" /dev/null'
p9431
f*345

After:

p9431
f12345

Test plan

• Verify -F fd output shows full fd number for fds >= 10000
• Verify normal tabular output still truncates as before (intended behavior)
• Verify -F fd output for non-numeric fds (cwd, txt, mem, etc.) is unchanged
• CI passes

[kurok]

Re: Cirrus CI failure on FreeBSD 14.3 — tests/LTbasic2

The failing test (LTbasic2) is unrelated to this PR's changes. Here's why:

• This PR modifies only src/print.c, specifically the -F field output code path — switching from fd_to_string() to direct printf("%d") for numeric FDs.
• LTbasic2 does not use the lsof CLI or field output. It tests the liblsof C API directly (lsof_new(), lsof_gather(), etc.) and validates results via struct fields (fd_type, fd_num, dev,
  inode). The code path this PR touches is never exercised by that test.
• All GitHub Actions CI runs on master are passing. The failure is isolated to the Cirrus CI / FreeBSD 14.3 environment.

Could a maintainer re-trigger the Cirrus CI check? If the failure persists, it may be worth tracking as a separate issue.

[jiegec]

Re: Cirrus CI failure on FreeBSD 14.3 — tests/LTbasic2

The failing test (LTbasic2) is unrelated to this PR's changes. Here's why:

* This PR modifies only src/print.c, specifically the -F field output code path — switching from fd_to_string() to direct printf("%d") for numeric FDs.

* LTbasic2 does not use the lsof CLI or field output. It tests the liblsof C API directly (lsof_new(), lsof_gather(), etc.) and validates results via struct fields (fd_type, fd_num, dev,
  inode).  The code path this PR touches is never exercised by that test.

* All GitHub Actions CI runs on master are passing. The failure is isolated to the Cirrus CI / FreeBSD 14.3 environment.

Could a maintainer re-trigger the Cirrus CI check? If the failure persists, it may be worth tracking as a separate issue.

This is a known CI failure, possibly due to cirrus CI putting the repo on /tmp where accurate file location is not available for lsof.

[kurok]

Re: Cirrus CI failure on FreeBSD 14.3 — tests/LTbasic2
The failing test (LTbasic2) is unrelated to this PR's changes. Here's why:

* This PR modifies only src/print.c, specifically the -F field output code path — switching from fd_to_string() to direct printf("%d") for numeric FDs.

* LTbasic2 does not use the lsof CLI or field output. It tests the liblsof C API directly (lsof_new(), lsof_gather(), etc.) and validates results via struct fields (fd_type, fd_num, dev,
  inode).  The code path this PR touches is never exercised by that test.

* All GitHub Actions CI runs on master are passing. The failure is isolated to the Cirrus CI / FreeBSD 14.3 environment.

Could a maintainer re-trigger the Cirrus CI check? If the failure persists, it may be worth tracking as a separate issue.

This is a known CI failure, possibly due to cirrus CI putting the repo on /tmp where accurate file location is not available for lsof.

I do not think this is caused by the repository location. CircleCI passes on BSD 15, so the issue seems more specific to the Cirrus CI / FreeBSD 14.3 environment than to the repo being placed under /tmp.