[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180328175425.GN1436@brightrain.aerifal.cx>
Date: Wed, 28 Mar 2018 13:54:25 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Maybe not a bug but a possible omission?
On Wed, Mar 28, 2018 at 07:19:49PM +0200, Szabolcs Nagy wrote:
> * Jon Scobie <jon.scobie@...lsign.com> [2018-03-28 14:33:23 +0100]:
> > Well, I definitely agree that instead of definitions like
> >
> > #define INT64_MIN (-1-0x7fffffffffffffff)
> >
> > we should have
> >
> > #define INT64_MIN (-1 - INT64_C(0x7fffffffffffffff))
> >
>
> why?
>
> "The macro INTN_C(value) shall expand to an integer constant expression corresponding to the type int_leastN_t"
>
> i dont think it is necessary or appropriate: the c rules
> already handles this portably: the const has the lowest
> rank 64bit signed int type, any additional complication
> can just get the type wrong.
Yes. If a tool is misinterpreting the expressions here, the tool
should be fixed. They all have the intended types already when
evaluated as C expressions. Making random edits to headers to make
buggy tools happy is not a direction I want to take.
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.
