docs: int is platform width, not always 32-bit

[quaesitor-scientiam]

The Primitive types note in doc/docs.md says:

Unlike C and Go, int is always a 32 bit integer.

That has not been true since #28293 (25f5ced70b), which made int platform width; that commit touched nothing under doc/. Checked against the generated C on master c9b806b294:

v -arch <arch> -o w.c of x := 19	C declaration
amd64	i64 x = 19;
i386	i32 x = 19;

Changes

1. The note now says int is 64 bits on 64-bit targets and 32 bits on 32-bit targets, and points to i32/i64 for a fixed width.

2. The raw inline-assembly example used addl on two int operands. Copied as written, it fails under gcc with the same error as Inline assembly tests use 32-bit mnemonic suffixes on platform-int operands, so they fail to assemble under gcc/clang #28870:

   Error: incorrect register `%rax' used with `l' suffix
   

   Its operands are now i32, followed by one sentence explaining why, since this is an easy trap for anyone porting 32-bit inline assembly.

example	-cc gcc	-cc <bundled tcc>
as written	assembler error	prints 42
with i32 operands	prints 42	prints 42

Checks

• All changed lines are ≤ 100 characters.
• v check-md doc/docs.md: 3 errors and 2 formatting errors, at lines 928, 6015 and 8833. Unmodified master reports exactly the same set at 927, 6014 and 8832 (the one-line shift is the longer note), so none come from this change. Both edits are prose or a v ignore block.

🧙 Built with WOZCODE

[quaesitor-scientiam]

No CI failure on #28876 comes from the PR. All three red checks fail the same way on master and on every other recent PR, including #28873 and #28874, which don't touch any Markdown. There's nothing to fix in this PR.

[JalonSolov]

There are several errors in examples. For instance, https://github.com/vlang/v/actions/runs/35810344048/job/107020291499?pr=28876#step:6:11 is saying that \141 is an invalid number... which is correct.

[quaesitor-scientiam]

There are several errors in examples. For instance, https://github.com/vlang/v/actions/runs/35810344048/job/107020291499?pr=28876#step:6:11 is saying that \141 is an invalid number... which is correct.

docs.md:927/:8832 on master been broken since 2026-08-21

To make it green again will require researching a separate fix

[quaesitor-scientiam]

You're right — both are real failures, and my date above was wrong: 2026-08-21 is only when master's Docs CI last passed. The two examples broke later, one day apart:

• docs.md:8832 (SQLite example) — broke on 2026-09-19, when 55d43d2192 started rejecting sql as a parameter name; the example declared fn C.sqlite3_exec(db &C.sqlite3, sql &char, ...). Fixed in this PR (fcf1bb2) by renaming the parameter to query.
• docs.md:927 (rune escapes) — broke on 2026-09-20 with 3b7b5eec98. The new character-literal validator doesn't consume the digits of an octal escape, so `\141` counts as three characters, and it also counts `\xe2\x98\x85` as three. Strings still accept both, and the docs describe both forms as working, so this is a scanner bug rather than a docs bug: filed as Rune literals reject octal escapes and multi-byte UTF-8 escapes (\141, \xe2\x98\x85) since 3b7b5eec98 #28880, fixed in scanner: accept octal and multi-byte escapes in rune literals (fix #28880) #28882. With only that fix, the whole rune example runs and passes under both tcc and gcc.

With both merged, check-markdown should be back to green (apart from anything newer).

[JalonSolov]

Now that #28882 has been merged, try merging master here to ensure the fix took care of things.

[quaesitor-scientiam]

If no further issues can this be merged

[JalonSolov]

See my comment just before yours.

[quaesitor-scientiam]

Now that #28882 has been merged, try merging master here to ensure the fix took care of things.

Rebased with master CI jobs running