Two C entry points return a size_t and are declared int on the Java side. The stub casts the result down, so the C compiler has nothing to warn about, and nothing anywhere compares the Java declaration with the C one.
/* bundles/org.eclipse.swt/Eclipse SWT PI/common/library/c.c:358 */
rc = (jint)strlen((char *)arg0);
/* string.h */ size_t strlen(const char *);
/* bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/os.c:9855 */
rc = (jint)wcslen((const wchar_t *)arg0);
/* wchar.h */ size_t wcslen(const wchar_t *);
The Java declarations:
/* Eclipse SWT PI/common/org/eclipse/swt/internal/C.java:144 */ public static final native int strlen (long s);
/* Eclipse SWT PI/win32/org/eclipse/swt/internal/win32/OS.java:4554 */ public static final native int wcslen (long string);
What it can cause
On LP64 size_t is 64-bit and jint is 32-bit, so the top 32 bits are dropped unconditionally. For a string of 2 GiB or more the returned length is wrong — and wrong in the worst way, because the cast makes it a plausible small number rather than an obvious failure.
Every call site uses the value directly as a length:
/* Eclipse SWT/gtk/org/eclipse/swt/graphics/Font.java:189 */ int length = C.strlen(family);
/* Eclipse SWT/win32/org/eclipse/swt/widgets/Display.java:3424 */ int length = OS.wcslen (sharedData);
I have not observed a failure and nothing was built or run. Whether a string that long reaches these calls is a question about SWT's own use, not about the declarations.
Suggested fix
SWT already models size_t as Java long everywhere else in the same file. C.java declares eighteen memmove overloads and memset, and every one takes a long annotated cast=(size_t):
/* C.java:141 */ public static final native long memset (long buffer, int c, long num); /* @param num cast=(size_t) */
strlen and wcslen are the only places size_t appears as a return, and the only two that use int. The repair would be to make them look like the rest — declare long and regenerate the stubs.
Call sites assign to int length, so each would need a cast or a wider local. TextLayout already writes one for the same kind of value:
/* Eclipse SWT/gtk/org/eclipse/swt/graphics/TextLayout.java:655 */
lineEnd = (int)OS.g_utf16_strlen(ptr, -1);
Provenance
Reported as part of ongoing research into cross-language boundaries. Every line above was checked against master on 2026-08-23. No runtime observation; nothing was built or run.
wcslen is Win32-only, where size_t is 64-bit under LLP64 as well, so the narrowing holds on both data models.
Two C entry points return a
size_tand are declaredinton the Java side. The stub casts the result down, so the C compiler has nothing to warn about, and nothing anywhere compares the Java declaration with the C one.The Java declarations:
What it can cause
On LP64
size_tis 64-bit andjintis 32-bit, so the top 32 bits are dropped unconditionally. For a string of 2 GiB or more the returned length is wrong — and wrong in the worst way, because the cast makes it a plausible small number rather than an obvious failure.Every call site uses the value directly as a length:
I have not observed a failure and nothing was built or run. Whether a string that long reaches these calls is a question about SWT's own use, not about the declarations.
Suggested fix
SWT already models
size_tas Javalongeverywhere else in the same file.C.javadeclares eighteenmemmoveoverloads andmemset, and every one takes alongannotatedcast=(size_t):strlenandwcslenare the only placessize_tappears as a return, and the only two that useint. The repair would be to make them look like the rest — declarelongand regenerate the stubs.Call sites assign to
int length, so each would need a cast or a wider local.TextLayoutalready writes one for the same kind of value:Provenance
Reported as part of ongoing research into cross-language boundaries. Every line above was checked against
masteron 2026-08-23. No runtime observation; nothing was built or run.wcslenis Win32-only, wheresize_tis 64-bit under LLP64 as well, so the narrowing holds on both data models.