From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12647 Path: news.gmane.org!.POSTED!not-for-mail From: Jon Scobie Newsgroups: gmane.linux.lib.musl.general Subject: Re: Maybe not a bug but a possible omission? Date: Thu, 29 Mar 2018 00:30:52 +0000 Message-ID: References: <20180328171948.GC4418@port70.net> <20180328175425.GN1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1141b9620b3a870568823d7b" X-Trace: blaine.gmane.org 1522283360 18609 195.159.176.226 (29 Mar 2018 00:29:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 00:29:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12661-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 29 02:29:15 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 1f1LRL-0004nW-Gi for gllmg-musl@m.gmane.org; Thu, 29 Mar 2018 02:29:15 +0200 Original-Received: (qmail 13641 invoked by uid 550); 29 Mar 2018 00:31:15 -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 13607 invoked from network); 29 Mar 2018 00:31:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callsign.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6aURuJF/Use8fQgpk1tV3XLTxfYG6rrV74CuiviWHj0=; b=Lwp7ZujbZs9LTeLpn1nSd/UBSyeOHjfeOTCH9yQ6SLr3nwEacVZrs8JxeXhOSnrgJk IlSonLlmj3Wit/v+wNoWGrHwGhAfq/GIdvIxqAFDzMEv50DD2wqMOsCFqV3JnQfCMPbf J4cKTy5yXwxuEqOLsRF8jie00Kq2X8SwluDOc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6aURuJF/Use8fQgpk1tV3XLTxfYG6rrV74CuiviWHj0=; b=hAW0wodLw7KuSTOWKSdwfxmn3fr/WYikZ7rptlHgxXWB27/GFigELttM2aA5pFFN5q Eu2ZURoZcK6ICgnqDHV45S2YgCIoIJ9oipAthghIYdifOKxby15Df/R6+rdr0PpMUNa2 h2fxSKgPL/hwsvUXTScHPk5ztV6lZFJZtlZ7H5+utzV61AxxXZv6PQmScz+hIV7LKmOu lnSHF1+w74Q/1ZyI0LT9kkrwYxHX475rvv4d0SW2ozMautFQHjE/7yewB7JP6qtrei+O mUsIxsN3b+p0msnzkC49lEEaHVIY1+zYMMdGLo2KLHisW06LLxZP/L3EEa6KUXi8Q379 X8+A== X-Gm-Message-State: AElRT7Ey0cXPWjhheUYpz3D1PA+FdHDpQcrx4q+OFrxk2LxyBoJWGhcA N43oyZIMze6h6/Y1J/6u6+dUTwu+13tqP3DsEh2GLhfrnFyzyrLFQEzlqJGqO8qeOy54f54iMYG 44H4LrU+9g3z9U9zgfNGXcFdpztenXI2I X-Google-Smtp-Source: AIpwx4+/RSm3ejieHehdpI5+MaI36NEhPLwR3RWoVn5cJKoOGp8o/lYzSvKaRvi8XUdf5qBP4OEu5QKGXWx+urlEnuA= X-Received: by 10.107.155.21 with SMTP id d21mr22792751ioe.243.1522283462730; Wed, 28 Mar 2018 17:31:02 -0700 (PDT) In-Reply-To: <20180328175425.GN1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12647 Archived-At: --001a1141b9620b3a870568823d7b Content-Type: text/plain; charset="UTF-8" Intended types? It's a macro. Where is the type definition? It is inferred. Why not just make it implicit when the language allows for it? On Wed, 28 Mar 2018, 18:54 Rich Felker, wrote: > 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. > > Rich > -- ---- The information contained in this communication is private and confidential and may contain privileged material. It is intended solely for use by the recipient(s). Copying, distributing, disclosing or using any of the information in it or any attachments is strictly prohibited and may be unlawful. --001a1141b9620b3a870568823d7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Intended types? It's a macro. Where is the type = definition? It is inferred. Why not just make it implicit when the language= allows for it?=C2=A0

On= Wed, 28 Mar 2018, 18:54 Rich Felker, <dalias@libc.org> wrote:
On Wed, Mar 28, 2018 at 07:19:49PM +0200= , Szabolcs Nagy wrote:
> * Jon Scobie <jon.scobie@callsign.com> [2018= -03-28 14:33:23 +0100]:
> > Well, I definitely agree that instead of definitions like
> >
> > #define INT64_MIN=C2=A0 (-1-0x7fffffffffffffff)
> >
> > we should have
> >
> > #define INT64_MIN=C2=A0 (-1 - INT64_C(0x7fffffffffffffff))
> >
>
> why?
>
> "The macro INTN_C(value) shall expand to an integer constant expr= ession 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


----
The information contained in this communication is pri= vate and confidential and may contain privileged material. It is intended s= olely for use by the recipient(s). Copying, distributing, disclosing or usi= ng any of the information in it or any attachments is strictly prohibited a= nd may be unlawful. --001a1141b9620b3a870568823d7b--