Skip to content

fix(portability): clean up unsafe uses of long for LLP64 - #65

Merged
got3nks merged 2 commits into
amule-org:masterfrom
got3nks:fix/long-portability-llp64
Jun 10, 2026
Merged

fix(portability): clean up unsafe uses of long for LLP64#65
got3nks merged 2 commits into
amule-org:masterfrom
got3nks:fix/long-portability-llp64

Conversation

@got3nks

@got3nks got3nks commented Jun 10, 2026

Copy link
Copy Markdown

Summary

Fixes #41. long is 32-bit on LLP64 (Windows 64-bit) but 64-bit on LP64 — every site flagged in @ngosang's audit is fixed here in one PR. Built clean on macOS (amule + amuled + amulecmd + amuleweb + amulegui, no warnings); CI will verify Ubuntu / mingw / macOS in all configurations.

Commit 1 — source fixes (+82/-41)

Commit 2 — translation catalog regen (+780/-780)

Output of ./scripts/update-po.sh. The webserver_pid format change altered two msgids (%ld%d), which msgmerge marks fuzzy in every catalog that previously translated them. Since the format specifier is the only difference and the format specifier appears identically in every translated msgstr, I un-fuzzied them mechanically: %ld%d in the msgstr, drop the fuzzy marker. No human translation work. Unrelated pre-existing fuzzy entries (e.g. the English (U.S.) marker from #60) are untouched.

The bulk of the diff is source-reference renumbering (#: comments) because the source-line shifts in commit 1 ripple through every catalog's reference comments. Drift check (msgcat --no-wrap, strip headers + #: refs) passes cleanly.

Test plan

  • CI green on all platforms.
  • Local macOS build clean (verified).
  • No behavioural change expected on LP64; visible improvements confined to LLP64 (Windows 64-bit) for file sizes > 4 GiB and download progress > 4 GiB.

got3nks added 2 commits June 10, 2026 21:14
Following the portability audit in amule-project#41, `long` is 32-bit on LLP64
(Windows 64-bit) but 64-bit on LP64, causing pointer truncation,
file-size truncation, and accidental narrowing through APIs typed as
`long`. This commit fixes every site flagged in the issue.

## Confirmed bugs

- WebServer.cpp / php_core_lib.cpp: ftell's `long` return wraps for
  >2 GiB template files on Win64. Capture into a 64-bit local with
  bounds check before narrowing. Won't bite a real user (templates
  are tiny) but fixes the type confusion at the source.
- TextClient.h: `unsigned long lFileSize` widened to `uint64`, with
  matching `%llu` printf format in TextClient.cpp. Fixes amulecmd's
  mis-display of any shared file > 4 GiB on Win64.

## InternalEvents API widening

- `CMuleInternalEvent::SetExtraLong` / `GetExtraLong` (carrying a
  `long m_value`) renamed to `SetExtraInt64` / `GetExtraInt64` with
  underlying type `int64_t`. The existing `HTTPDownload.cpp:312`
  caller already routes a `wxFileOffset` (potentially > 4 GiB)
  through it via an explicit `(long)` cast that silently truncated
  on Win64; the cast is now dropped.
- All 16 callsites updated to the new name across `amule.cpp`,
  `amule-remote-gui.cpp`, `AsyncDNS.cpp`, `HTTPDownload.cpp`. Drop
  the stale `(long)m_result` cast at HTTPDownload.cpp:417 too.

## Pointer-to-integer casts → uintptr_t

- FileArea.cpp: pointer arithmetic in the SIGBUS handler used
  `unsigned long`, which would truncate pointers on Win64. POSIX-only
  path today, but worth fixing.
- MuleDebug.cpp: same in the bfd backtrace `s_pie_base` subtraction.

## Process IDs → int

- `webserver_pid` (amule.h, TerminationProcessAmuleweb.h/.cpp,
  amule.cpp call sites) changed from `long` to `int`. POSIX pid_t
  is typically `int`, Windows DWORDs fit in `int`, and `int` avoids
  `pid_t`'s portability wart on MSVC. Format strings updated from
  `%ld` to `%d`; the wxExecute return is now narrowed explicitly.
- AppImageIntegration.cpp: drop the `static_cast<long>(getpid())`
  -- getpid returns pid_t (int on every aMule target), no cast
  needed; format updated to `%d`.

## PartFileConvert intermediate

- Switch `long l + ToLong + (unsigned) cast` to
  `unsigned long l + ToULong + uint32 cast`. File indices are small
  in practice; the new pattern makes the type intent explicit.

Refs amule-project#41.

Build verification: macOS `cmake --build` of amule + amuled +
amulecmd + amuleweb + amulegui completes warning- and error-free on
the patched tree.
The portability commit changed two msgids -- the two "Terminating /
Killing amuleweb instance with pid '%d' ... " log messages -- from
`%ld` to `%d` to match the new `int` type of `webserver_pid`.
CFormat is type-safe so the rendered output is unchanged, but the
extracted msgids drift so the .pot and every .po has to be regenerated.

msgmerge marked the two updated entries `#, fuzzy` in each catalog
that previously translated them. The only difference between the old
and new msgstr is the same %ld -> %d swap, so this is a mechanical
fix: each affected msgstr has its `%ld` replaced with `%d` and the
fuzzy marker dropped. No human translation work needed -- all
languages keep their existing wording.

Catalogs that already had the entries untranslated, and unrelated
pre-existing fuzzy entries (e.g. the English (U.S.) marker from
PR amule-project#60), are left untouched.
@got3nks
got3nks merged commit 2c3fa3e into amule-org:master Jun 10, 2026
10 checks passed
@got3nks
got3nks deleted the fix/long-portability-llp64 branch June 10, 2026 19:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Portability review: unsafe uses of the long type (LLP64 vs LP64)

1 participant