casaroli opened a new pull request, #21500:
URL: https://github.com/apache/nuttx/pull/21500
## Summary
`int_fast16_t` and `uint_fast16_t` are `int` and `unsigned int`, but their
limits and formats are the 16-bit ones. Where `int` has 32 bits,
`INT_FAST16_MAX` is 32767, and `SCNdFAST16` is `%hd`, so `sscanf()` stores 2 of
the 4 bytes:
```c
int_fast16_t a = -1;
sscanf("5", "%" SCNdFAST16, &a); /* a is -65531 on a little endian CPU */
```
GCC reports it: `format '%hd' expects argument of type 'short int *', but
argument 3 has type 'int_fast16_t *'`.
This PR takes the limits from `INT_MIN`, `INT_MAX` and `UINT_MAX`, and uses
the formats of `int`. The type does not change.
## Impact
`INT_FAST16_MIN`, `INT_FAST16_MAX`, `UINT_FAST16_MAX` and the `PRI*FAST16`
and `SCN*FAST16` macros change, on all architectures that use
`include/stdint.h`. nuttx and nuttx-apps do not use the three limits. The size
of the type stays the same, so no ABI changes. No documentation names these
macros.
## Testing
A test program: the three limits against the size of the type, `printf()` of
the maximum with `PRIdFAST16`, `sscanf()` with `SCNdFAST16` and `SCNuFAST16`
into an object of all ones. qemu-armv8a under QEMU, GCC 14.2:
| | master | this PR |
|---|---|---|
| qemu-armv8a:nsh (flat) | 6 of 8 checks fail: the limits, the print and
both scans | 8 of 8 pass |
| qemu-armv8a:knsh (kernel) | not run | 8 of 8 pass |
Not run: a target where `int` has 16 bits. There `INT_MAX` is 32767 and `%d`
is the same size as `%hd`, so nothing changes. arch/ceva has its own scan
formats, also changed; no ceva toolchain here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
