Hi Paul,
Paul Eggert <egg...@cs.ucla.edu> writes:
> * src/od.c (width_bytes, decode_one_format): Don’t assume a signed
> type has the same size as the corresponding unsigned type.
> This has no effect on practical platforms; it’s just for
> consistency there.
> ---
> src/od.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/src/od.c b/src/od.c
> index c3c76cc86..50319aa83 100644
> --- a/src/od.c
> +++ b/src/od.c
> @@ -131,15 +131,15 @@ struct tspec
> static const int width_bytes[] =
> {
> -1,
> - sizeof (char),
> + sizeof (unsigned char),
> #if UCHAR_MAX < USHRT_MAX
> - sizeof (short int),
> + sizeof (unsigned short int),
I haven't looked at all the patches (started backwards). But regarding
the commit message, the assumption is safe if we assume ISO C
conformance. C99 states in § 6.2.5:
For each of the signed integer types, there is a corresponding (but
different) unsigned integer type (designated with the keyword
unsigned) that uses the same amount of storage (including sign
information) and has the same alignment requirements.
C23 has similar wording for the *_WIDTH macros that it added. For
U?INT_WIDTH for example, from § 5.2.5.3.2:
The macro INT_WIDTH represents the width of the type int and shall
expand to the same value as UINT_WIDTH.
The patch is fine, and looks a bit cleaner when matching the U*_MAX in
preprocessor directives. But figured I should let you know about those
sections of the C standard if you did not know them already.
Collin
