Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130120043721.GM20323@brightrain.aerifal.cx>
Date: Sat, 19 Jan 2013 23:37:21 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Make bits/wchar.h correct for all architectures (bug
 15036) (fwd)

On Sat, Jan 19, 2013 at 11:25:59AM -0800, Isaac Dunham wrote:
> On Sat, 19 Jan 2013 08:58:40 -0500
> Strake <strake888@...il.com> wrote:
> 
> > 
> > On 18/01/2013, Rich Felker <dalias@...ifal.cx> wrote:
> > > I think the same issues apply to musl, and the solution seems very
> > > elegant. Maybe we can apply the same thing. What do you think?
> > 
> > What if int is not 32-bit?
> 
> Not possible on a (current) POSIX system, to the best of my knowledge.
> Also not compatible with any glibc or LSB abi, or any Linux port.
> 
> In other words: Unless you're planning to port musl to ELKS or
> Win16/Win64, you're joking. And I would venture to say that you
> would be joking in those cases, too.

I think Strake's concern was not about 16-bit int (which POSIX
precludes) but rather the possibility of 64-bit int or such. For
better or worse, there are many practical reasons int should never be
larger than 32-bit, the most serious of which are connected to the
side effects of integer promotion rules. And in any case, all relevant
systems (keep in mind this is musl, not an application, so it can
assume its own implementation details) have 32-bit int and always
will.

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.