Skip to content

[FIX] Use fixed-width format specifiers for 64-bit values (corrupted X-TIMESTAMP-MAP on Windows) - #2337

Open
pranayr710 wants to merge 1 commit into
CCExtractor:masterfrom
pranayr710:fix/format-specifiers-64bit-windows
Open

[FIX] Use fixed-width format specifiers for 64-bit values (corrupted X-TIMESTAMP-MAP on Windows)#2337
pranayr710 wants to merge 1 commit into
CCExtractor:masterfrom
pranayr710:fix/format-specifiers-64bit-windows

Conversation

@pranayr710

@pranayr710 pranayr710 commented Sep 8, 2026

Copy link
Copy Markdown

Fixes #2336

Reason for this PR:

  • This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists. (see the caveat on "sample" under Repro below — this one is reproducible without a media file, and I've included an exact reproduction)

Sanity check:

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • This is a bug fix, so I have NOT added it to the changelog.
  • I am NOT adding new C code — this only corrects format specifiers and one wrong field reference in existing lines.

What was wrong

X-TIMESTAMP-MAP carried a corrupted MPEGTS value on every Windows build:

// ccx_encoders_webvtt.c:224
snprintf(..., "X-TIMESTAMP-MAP=LOCAL:%02u:%02u:%02u.%03u,MPEGTS:%ld%s",
         h1, m1, s1, ms1, context->timing->sync_pts2fts_pts, ...);

sync_pts2fts_pts is LLONG → int64_t, printed with %ld. long is 32 bits on Windows (LLP64 on x64, ILP32 on Win32), so the value is truncated. HLS players use this field to anchor a WebVTT segment to the transport clock.

Linux/macOS are LP64 where long is 64 bits, so %ld is accidentally correct there — which is why this survived.

Repro instructions

No media sample is needed — this is a type/format mismatch that the compiler itself diagnoses. I understand the template asks for a sample and why; I'm happy to hunt one down for the regression suite if you want it, but I don't think a file is what makes this one verifiable. Here is the proof instead.

1. The compiler flags the real line. Building the actual file with MinGW-w64 (same LLP64 ABI as the shipped MSVC binaries):

$ gcc -fsyntax-only -Wformat -DDISABLE_RUST -Isrc -Isrc/lib_ccx ... src/lib_ccx/ccx_encoders_webvtt.c

src/lib_ccx/ccx_encoders_webvtt.c:225:64: warning: format '%ld' expects argument of type
'long int', but argument 8 has type 'LLONG' {aka 'long long int'} [-Wformat=]
  226 |     h1, m1, s1, ms1, context->timing->sync_pts2fts_pts,
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      | note: format string is defined here ... %lld

2. Standalone runnable reproduction (gcc -Wall repro.c && ./repro on Windows x86_64):

#include <stdio.h>
#include <stdint.h>
typedef int64_t LLONG;
int main(void) {
    char h[200]; unsigned h1=0,m1=0,s1=0,ms1=0;
    LLONG pts = 8589934592LL;             /* 2^33, an ordinary 90kHz PTS */
    printf("sizeof(long) = %d\n", (int)sizeof(long));
    snprintf(h,sizeof h,"MPEGTS:%ld",  pts); printf("current -> %s\n", h);
    snprintf(h,sizeof h,"MPEGTS:%lld", pts); printf("fixed   -> %s\n", h);
    return 0;
}

Actual output:

sizeof(long) = 4
current -> MPEGTS:0
fixed   -> MPEGTS:8589934592

A PTS of 2^31 (≈6.6 h of 90 kHz ticks) prints MPEGTS:-2147483648 — negative, which is invalid for this field. On Win32 it is worse: cdecl varargs are stack-packed, so %ld eats 4 of 8 bytes and the trailing %s reads the PTS high dword as a char *.

Why PRId64 and not %lld

%lld would fix Windows but break Linux, where int64_t is long, not long long. The <inttypes.h> macros are correct on every target, are already used in ccx_demuxer_mxf.c, ccx_encoders_curl.c, dvb_subtitle_decoder.c and telxcc.c, and ccx_common_platform.h already includes <inttypes.h>, so no new include is needed.

Scope: 22 sites, one root cause

mprint() and dbg_print() carry no __attribute__((format(printf, ...))), so the compiler never checks those call sites — the whole class is invisible to the build. I added the attributes locally, rebuilt src/lib_ccx/*.c with -Wformat, and fixed everything it found:

  • PRId64 / PRIu64 / PRIx64 for int64_t / uint64_t / LLONG / ULLONG
  • %zu for size_t
  • explicit (long long) cast for pointer differences

After the fix that build is clean (the only three diagnostics left are checker artifacts, not defects — details in #2336).

One genuine second bug

ts_functions.c:345 printed payload->start, an unsigned char *, under the label "PES start". The intended field is payload->pesstart. The pointer was truncated to int and shifted the three arguments after it, so counter, payload length and adapt length were all wrong in every -debug TS trace.

Risk

Output on Linux and macOS is byte-identical before and after. Only Windows output changes, from wrong to right. No signature, struct, option or output-format change. clang-format clean.

Deliberately left out

  • matroska.c:1348/1594 use the LLD macro, which expands to %I64d on Windows and is correct. GCC only reported it because its gnu_printf checker skips the MSVC I64 modifier. Untouched.
  • I did not add the format(printf) attributes to mprint/dbg_print in this PR, even though that is what would stop this class from coming back. I can only test the Windows leg locally, and I'd rather not surface unknown warnings on the Linux build without your say-so. Happy to send it as a follow-up if you want it.

Disclosure: I found this with AI assistance, then verified every claim on real hardware — the compiler diagnostics and program output above are captured from actual runs on Windows, not inferred. I saw the note in the PR template about theoretical AI-generated fixes and tried to make this one carry its own proof.

@pranayr710
[FIX] Use fixed-width format specifiers for 64-bit values
290d79c 
X-TIMESTAMP-MAP emitted a truncated MPEGTS value on every Windows build.
sync_pts2fts_pts is LLONG (int64_t) but was printed with %ld, and long is
32 bits on Windows (LLP64 on x64, ILP32 on Win32). A 90kHz PTS of 2^33
printed as "MPEGTS:0"; 2^31 printed as "MPEGTS:-2147483648". On Win32 the
argument slots also desynchronise, so the trailing %s reads the PTS high
dword as a char *. HLS players use this field to anchor a WebVTT segment
to the transport clock, so the result is caption desync.

Linux and macOS are LP64, where long is 64 bits and %ld happens to be
correct, which is why this went unnoticed. For the same reason %lld would
be wrong there, since int64_t is long on LP64. Use the <inttypes.h> macros
instead, which are correct on every target and already used elsewhere in
the tree; ccx_common_platform.h already includes <inttypes.h>.

The same defect class appears at 22 sites across 10 files. They are
invisible to the build because mprint() and dbg_print() carry no
format(printf) attribute, so the compiler never checks those call sites.
Adding the attributes locally surfaced all of them; this commit fixes them
with PRId64/PRIu64/PRIx64 for fixed-width types, %zu for size_t, and an
explicit (long long) cast for pointer differences.

Also fixes ts_readpacket() printing payload->start, an unsigned char *,
under the label "PES start". The intended field is payload->pesstart; the
pointer was truncated to int and shifted the three arguments after it, so
counter, payload length and adapt length were all wrong in the trace.

Output on Linux and macOS is byte-identical before and after. No
signature, struct, option or output-format change.

Refs CCExtractor#2336
@ccextractor-bot

ccextractor-bot commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator
CCExtractor CI platform finished running the test files on linux. 171/237 tests matched the approved output:
Report Name Tests Passed
Broken 9/13
CEA-708 2/14
DVB 0/7
DVD 3/3
DVR-MS 2/2
General 25/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 69/86
Teletext 0/21
WTV 12/13
XDS 32/34

66 tests do not match the approved output. That is the pass/fail verdict. Whether this branch caused it is a separate question, answered below.

Compared with the tip of master — test 9528, commit 205cfb0:

  • 0 pass there and fail here
  • 0 fail there and pass here
  • 0 fail on both, with different output
  • 66 fail on both, byte for byte the same

Compared with the commit this branch was cut from: the same run as the tip of master (test 9528), so the comparison above already covers it.


No test changes behaviour relative to the tip of master: every failure above fails there too, byte for byte. The approved output for those tests is out of date, which is a baseline to review rather than a regression in this branch.

@ccextractor-bot

ccextractor-bot commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator
CCExtractor CI platform finished running the test files on windows. 171/237 tests matched the approved output:
Report Name Tests Passed
Broken 9/13
CEA-708 2/14
DVB 0/7
DVD 3/3
DVR-MS 2/2
General 25/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 69/86
Teletext 0/21
WTV 12/13
XDS 32/34

66 tests do not match the approved output. That is the pass/fail verdict. Whether this branch caused it is a separate question, answered below.

Compared with the tip of master — test 9525, commit 3875e84:

  • 0 pass there and fail here
  • 0 fail there and pass here
  • 0 fail on both, with different output
  • 66 fail on both, byte for byte the same

Compared with the commit this branch was cut from: the same run as the tip of master (test 9525), so the comparison above already covers it.


No test changes behaviour relative to the tip of master: every failure above fails there too, byte for byte. The approved output for those tests is out of date, which is a baseline to review rather than a regression in this branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

2 participants

@pranayr710 @ccextractor-bot