Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Mar 2018 13:54:25 -0400
From: Rich Felker <>
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 <> [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.


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.