From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9133 Path: news.gmane.org!not-for-mail From: Josiah Worcester Newsgroups: gmane.linux.lib.musl.general Subject: Re: the size of the int type Date: Fri, 15 Jan 2016 21:11:25 +0000 Message-ID: References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd6c5122086b0052965d9a6 X-Trace: ger.gmane.org 1452892310 7506 80.91.229.3 (15 Jan 2016 21:11:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jan 2016 21:11:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9146-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 15 22:11:50 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aKBev-0007lL-9g for gllmg-musl@m.gmane.org; Fri, 15 Jan 2016 22:11:49 +0100 Original-Received: (qmail 32692 invoked by uid 550); 15 Jan 2016 21:11:47 -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 32664 invoked from network); 15 Jan 2016 21:11:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=lDurALK9wP6fP31ZBcGTQvT+6hBR1pFFqKOh5hw4ZOs=; b=wB/xCkOt0BqUe5CWAe1ng6z6ROI7lKJbBQ5njcRKU2NiyZCSGBrOFroV3Wwb3HidrI uqynaHvnKQ++V4xP4UQKJRQmzjPawviI0wwkcZwGhLSnnUwi2GzoZ+8I8bSLkc0Hz8k3 K+kv4akKitxrzc6+85infzuoLnlFfs1R2of7xCnzWKHOglQXa7Ii9u9sbUvlaOGPqTle h9JaY5XsyEAdAwaAQeUqmbdqgDaKO2q6Ji/7+BsrP/A0Ay6m4BgncF8chL0GYLvlt69z it4wCgf3GtGznv6FFiq7cRbEwHuJKshc+1N6fMAlEI0cSl1allGwqtjdzMJfizVGL7vS J+EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=lDurALK9wP6fP31ZBcGTQvT+6hBR1pFFqKOh5hw4ZOs=; b=SFXocdnAHCAaUGlYUGZ84Y4Y6ZI/ps0+WZpX52mZ31DZwQYwHoM/+BDWPe7kuTUL+8 rv/n0Bj70zmPRGkjkpFE9MWScrQq8WaXonGaTeAcVkGjX+EEQYmX1jVAaOFVJJnc1uYK PZ8B8PCEusXmm1VEOhuzjQJ6Csk+WAsC7yBjFmlE1zF16tdEJxwrOla0ne1/75j76G+f ED9tKnKf8lG7aezByFHi/qWDUxJtpWblxmzqDbiAlWw7pbwGiMZBluKmRYWFryX3K1ik /qyXB07O7i1RDbeTQ6/bOpwqr5oCvDZpSKnyRhZrFWt15vvBgTkgXJ9Br6zapJ55Aswi HQTQ== X-Gm-Message-State: AG10YOSuDMXe4It7ckZQ3/bO8l71KPeUpVn7SORrvPokLpir+IA6Wrv8xPa63t/9rjGmagzCCHA9gn5RVILeiQ== X-Received: by 10.60.155.97 with SMTP id vv1mr3625266oeb.60.1452892294774; Fri, 15 Jan 2016 13:11:34 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:9133 Archived-At: --047d7bd6c5122086b0052965d9a6 Content-Type: text/plain; charset=UTF-8 I do not know of anything in musl that assumes "int" is 32-bit, but I'm confident that implementing it as anything else will break a large amount of third party code. Practically all platforms in common use have 32-bit int (regardless of the machine's word size), and as such a lot of code relies on this (implicitly or explicitly). You would do better to match the convention used on modern-day Unix systems, where int is 32-bit, long is the machine word size, and long long is 64-bit. If you do this everything should pretty much function as it expects, with regard to the standard C types' sizes. On Fri, Jan 15, 2016 at 1:01 PM Max Ruttenberg < mruttenberg@emutechnology.com> wrote: > Hi, > > I'm wondering if there's any code in musl that makes assumptions on the > size of the "int" type. > > I only ask because I'm debating how my compiler (which targets a machine > with a 64-bit word size) should define the int type. Ideally I'd like to > break as little library code as possible. > > Max > --047d7bd6c5122086b0052965d9a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not know of anything in musl that assumes "int&q= uot; is 32-bit, but I'm confident that implementing it as anything else= will break a large amount of third party code. Practically all platforms i= n common use have 32-bit int (regardless of the machine's word size), a= nd as such a lot of code relies on this (implicitly or explicitly).
You = would do better to match the convention used on modern-day Unix systems, wh= ere int is 32-bit, long is the machine word size, and long long is 64-bit. = If you do this everything should pretty much function as it expects, with r= egard to the standard C types' sizes.

On Fri, Jan 15, 2016 at 1:01 PM Max Ruttenberg <mruttenberg@emutechnology.com<= /a>> wrote:
--047d7bd6c5122086b0052965d9a6--