Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141202215634.GJ29621@brightrain.aerifal.cx>
Date: Tue, 2 Dec 2014 16:56:34 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 4/4] fix a minor bug for the definition of WINT_MIN

On Tue, Dec 02, 2014 at 10:42:57PM +0100, Jens Gustedt wrote:
> Am Dienstag, den 02.12.2014, 14:47 -0500 schrieb Rich Felker:
> > On Tue, Dec 02, 2014 at 08:23:18PM +0100, Jens Gustedt wrote:
> > > > 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.
> 
> ah right, and since we heavily rely on linux we don't assume that we
> will ever run on a non-POSIX platform
> 
> > > > 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.
> 
> So that's probably the reason why it is burried in the arch specific
> stuff. So I see two solutions
> 
>  - have it as I did, be symmetric, and burry it in the arch specific
>    files
> 
>  - have it in one place, but then bluntly use unsigned, UINT_MAX and 0U
> 
> I have no personal preference for any of that.

One simple definition that seems to work and naturally gets the types
right:

#define WINT_MAX 0xffffffffu
#define WINT_MIN (WINT_MAX-WINT_MAX)

Note that UINT_MAX isn't available in stdint.h; this was probably the
original motivation for using UINT32_MAX. But spelling it out as
0xffffffffu explicitly works just as well.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.