From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12643 Path: news.gmane.org!.POSTED!not-for-mail From: CodingMarkus Newsgroups: gmane.linux.lib.musl.general Subject: Re: Maybe not a bug but a possible omission? Date: Wed, 28 Mar 2018 14:52:28 +0200 Message-ID: References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522241442 14295 195.159.176.226 (28 Mar 2018 12:50:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 12:50:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12657-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 28 14:50:38 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f1AXG-0003bS-1S for gllmg-musl@m.gmane.org; Wed, 28 Mar 2018 14:50:38 +0200 Original-Received: (qmail 12235 invoked by uid 550); 28 Mar 2018 12:52:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12212 invoked from network); 28 Mar 2018 12:52:41 -0000 X-Virus-Scanned: amavisd-new at heinlein-support.de In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12643 Archived-At: > On 2018-03-28, at 12:31, Jon Scobie wrote: >=20 > #define INT64_MIN (-1-0x7fffffffffffffff) >=20 > the equivalent glibc definition is the equivalent of >=20 > #define INT64_MIN (-1-0x7fffffffffffffffL) According to ISO-C 2011 standard (page 63): "The type of an integer constant is the first of the corresponding list = in which its value can be represented.=E2=80=9D And for constants that have no type suffix (no =E2=80=9CL=E2=80=9D, = =E2=80=9CLL=E2=80=9D, =E2=80=9CU=E2=80=9D, =E2=80=9CUL=E2=80=9D, = =E2=80=9CULL=E2=80=9D), the =E2=80=9Clist=E2=80=9D mentioned above = contains the following types decimal values: int, long int, long long int and the following types of octal/hex values: =20 int, unsigned int, long int, unsigned long int, long long int, unsigned = long long int Thus the type is the first one of the three above that is big enough to = represent a constant value.=20 By using the suffix =E2=80=9CL=E2=80=9D, all that happens is that the = type list is further limited down to: long int, long long int or for octal/hex values: long int, unsigned long int, long long int, unsigned long long int On most systems, only long int or long long int can represent = "(-1-0x7fffffffffffffff)=E2=80=9D, so either one will be the deferred = type. Appending the suffix =E2=80=9CL=E2=80=9D would thus not make any = difference, as it will not result in a different type. It only = eliminates the type =E2=80=9Cint=E2=80=9D from the list but I don=E2=80=99= t know any system where the type int could represent such a big number, = so int is never chosen to begin with. Personally I wonder about that definition in both libraries, I had = expected it to be: #define INT64_MIN INT64_C(...) because that assures the type is pinned to whatever type int64_t maps on = the system. After all the C standard also says about INT64_MIN the other = defines: "Each instance of any defined macro shall be replaced by a constant = expression suitable for use in #if preprocessing directives, and this = expression shall have the same type as would an expression that is an = object of the corresponding type converted according to the integer = promotions.=E2=80=9D So INT64_MIN should be the same type as int64_t is (that=E2=80=99s how I = interpret the last part of that sentence) and that is not always = guaranteed when defined as above, as when defined as above, a long int = is enough to represent that type on a 64 bit system (on 64 bit systems, = long is typically 64 bit already), whereas int64_t may as well be a long = long int on such a system. At least PRI64d typically uses =E2=80=9Clld=E2=80= =9D AFAIK and not =E2=80=9Cld=E2=80=9D, though I have not checked what = musl or glibc uses for PRI64d on 64 bit systems. > The issue is that swig has no idea what type INT64_MAX is if you don't = specifically state what it is so it treats it as a goint - which is not = a long (or long long). If swig fails to correctly process valid C code, then this sounds like a = bug that the swig developers should really fix. The type of a numeric = constant is always exactly defined by the C standard, it=E2=80=99s never = required to give an explicit type unless you want a =E2=80=9Cwider=E2=80=9D= type than would have been chosen automatically otherwise or you want to = force a signed value to be an unsigned type. Every tool parsing, = compiling or processing C code should know the type rules and should = apply them the same way a C compiler would do it, shouldn=E2=80=99t it? Regards, Markus