LoadTexture, UnloadTexture, the four DrawTexture variants and IsTextureValid. Nothing about them pushes against the aggregate rule: every raylib signature here takes its structs by value, and every one has an obvious pointer form the shim dereferences, so the declarations are scalars and pointers as before. The predicate is IsTextureValid and not IsTextureReady, which this version of raylib does not export at all — 5.5 renamed it, and calling the old name would be a link error rather than a silent miss. It is bound because the failure it reports is otherwise invisible: LoadTexture on a missing file returns a texture with an id of 0 and says so only on the trace log, and then every draw with it is a no-op that looks like a drawing bug. cstr's one caller used to be the window title, and its comment said so. A path is the second caller and wants far more than 256 bytes, so each caller now passes a buffer sized for what it holds. Truncating still beats reading past the end: a truncated path simply fails to open, and texture-valid? is how the program notices. None of this is in the acceptance table, and deliberately. Loading a texture needs a GL context, so anything headless would be asserting on the failure path while appearing to test the working one. It is exercised by sand.flan.
Description
Languages
OCaml
67.2%
Emacs Lisp
15.2%
C
10.4%
HTML
2.9%
Standard ML
2.8%
Other
1.5%