Subsequent to TIP 476, the `format` command accepts new size field specifiers t,z,j,q,I,I32,I64. These are not documented in the manpage.

Additionally, I think the "j" "z" and "t" specifiers do not match the C printf (assuming that is the intent). They are supposed to be sizeof intmax_t, size_t and ptrdiff_t respectively but in `format` they do not seem to truncate to fit those sizes (unlike "l" for example). Is that intentional?

I think the documentation problems are corrected now, and the behavior of "j"/"z"/"t" as well. Thanks for the testcases!

Regarding 'hp', it looks like the c99 printf simply ignores the 'h' while we handle it as expected (however useless that is ....). I don't think we should do anything about it.

On %a/%A, I think both Windows and UNIX output look OK, it's not clear from the documentation whether ending '0' digits may be removed or not, that's the difference. I don't think it's important enough to do anything about it.

Regarding 'I'/'I32'/'I64', can you agree on leaving it undocumented but only make it available on Windows? See: [01e6a242c4fc275c]. It's actually only intended for Tcl_ObjPrintf() on Windows, it doesn't make sense for 'format'.

I added experimental tests in a bug-9c258a841a-tests branch which show some differences w.r.t C99 (not necessarily bugs since some are definitely documented). More to flush out any differences and resolve as bugs or works as designed. Run make test with "-f format.test -match *c99*"

I agree all accepted specifiers, modifiers etc. should be documented. I am not sure a TIP is needed though I suppose no harm. TIP 476 already covers them I thought except it's missing some detail about semantics. The presumption would be that unless stated otherwise, they should produce the same result as C99 printf.

Thinking more about it, %z and %t should be documented and match C. Further on, %d without any specifier should truncate for 32-bit always, also matching C.

I see a TIP coming ....

> If neither h nor l nor L are present, the integer value is truncated to the same range .....

I think this sentence is wrong: If we want to have C behavior, %d should be 32-bit always. Doesn't Tcl 8.6 do that too?

Also the documentation for %p is wrong: It refers to the "z" specifier, which is not documented .....

> Are j, z, t supposed to match C?

Those specifiers are not documented for "format" on purpose: They are meant to be used from C (Tcl_ObjPrintf), not at script level. So, if someone uses it from a Tcl script, any behavior is fine, as long as Tcl_ObjPrintf() continues working as it does now.

> Is format %d supposed to match int() ?

No, see TIP #514

> Is int() supposed to match tcl_platform(wordSize)?

No, see TIP #514

Another inconsistency - manpage says

*If neither h nor l nor L are present, the integer value is truncated to the same range as that produced by the int() function of the expr command (at least a 32-bit range, but determined by the value of the wordSize element of the tcl_platform array)*

However, on Windows above does not hold

```
% set x 0x7ffffffff
0x7ffffffff
% format %x $x
ffffffff
% format %llx [expr int($x)]
7ffffffff
```

The mathfunc manpage is also inconsistent with this behavior

*The argument may be any numeric value. The integer part of arg is determined, and then the low order bits of that integer value up to the machine word size are returned as an integer value. For reference, the number of bytes in the machine word are stored in the wordSize element of the tcl_platform array.*

I can start on fixing up these issues but I am not sure what the behavior is supposed to be. Are j, z, t supposed to match C? Is format %d supposed to match int() ? Is int() supposed to match tcl_platform(wordSize)? Which part of mismatches is to be fixed?...

A further nit, %a and %A differ between Windows and Linux (or probably VC vs gcc)

Windows:

```
% format %A 16
0x1.0000000000000p+4
```

Linux:

```
% format %a 16
0x1p+4
```

Format manpage says default precision is 13 so the Windows version appears correct.

Based on the output below, I think j, t, z are not what I would expect as per their C printf definition (assuming that is the goal). They should truncate values that do not fit in intmax_t, ptrdiff_t, size_t to the appropriate size (32 or 64-bit depending on architecture). I would certainly find that useful in FFI type extensions.

```
% set int64 0x8000000000000001
0x8000000000000001
% set int65 0x10000000000000000
0x10000000000000000
% foreach t {d u} {foreach s {{} j l ll t z I I32 I64} {puts "$s$t\t[format %$s$t $::int64] [format %$s$t $::int65]"}}
d       1 0
jd      9223372036854775809 18446744073709551616
ld      -9223372036854775807 0
lld     9223372036854775809 18446744073709551616
td      9223372036854775809 18446744073709551616
zd      9223372036854775809 18446744073709551616
Id      1 0
I32d    1 0
I64d    -9223372036854775807 0
u       1 0
ju      9223372036854775809 18446744073709551616
lu      9223372036854775809 0
llu     9223372036854775809 18446744073709551616
tu      9223372036854775809 18446744073709551616
zu      9223372036854775809 18446744073709551616
Iu      1 0
I32u    1 0
I64u    9223372036854775809 0
```