Re: [PATCH 4/4] fix a minor bug for the definition of WINT_MIN

[Rich Felker <dalias@libc.org>]

On Tue, Dec 02, 2014 at 08:23:18PM +0100, Jens Gustedt wrote:
> Am Dienstag, den 02.12.2014, 13:06 -0500 schrieb Rich Felker:
> > On Tue, Nov 25, 2014 at 03:50:17PM +0100, Jens Gustedt wrote:
> > > This must be an unsigned value.
> > > ---
> > >  include/stdint.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/include/stdint.h b/include/stdint.h
> > > index 8b91163..8b81ca0 100644
> > > --- a/include/stdint.h
> > > +++ b/include/stdint.h
> > > @@ -78,7 +78,7 @@ typedef uint64_t uint_least64_t;
> > >  #define INTMAX_MAX  INT64_MAX
> > >  #define UINTMAX_MAX UINT64_MAX
> > >  
> > > -#define WINT_MIN 0
> > > +#define WINT_MIN (+_UINTEGER_C(uint32_t, 0))
> > >  #define WINT_MAX UINT32_MAX
> > 
> > Indeed, but 0U would be a much nicer way of writing it.
> 
> But this would be wrong on platforms with 16 bit int, no?

POSIX requires int to be at least 32 bits.

> > Also I'm wondering why I have wint_t in the arch-specific
> > alltypes.h.in files if stdint.h is assuming the type is
> > unsigned/32-bit, and it actually is for all archs. Perhaps we should
> > move it into the shared part of alltypes.h.in?
> 
> don't we have archs with 16 bit int?

No. And we don't have archs with int > 32 bits either because too much
would break with no practical benefits. (For example, uint32_t would
be smaller than int and thus would be subject to default promotions,
UB on overflow, etc. and there would be no way to get either a 16-bit
type or a 32-bit type without extended integer types.)

> but right, even then we could move it up and define it as uint32_t

That would not work directly, as wint_t is exposed in places that
don't expose uint32_t.

Rich