From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2308 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysinfo padding question Date: Sun, 18 Nov 2012 15:46:02 -0500 Message-ID: <20121118204602.GV20323@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1353271577 30028 80.91.229.3 (18 Nov 2012 20:46:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2012 20:46:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2309-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 18 21:46:26 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TaBl3-00066T-6m for gllmg-musl@plane.gmane.org; Sun, 18 Nov 2012 21:46:25 +0100 Original-Received: (qmail 18022 invoked by uid 550); 18 Nov 2012 20:46:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18013 invoked from network); 18 Nov 2012 20:46:14 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2308 Archived-At: On Sun, Nov 18, 2012 at 08:25:48PM +0000, Justin Cormack wrote: > Why is the padding for sysinfo for the kernel different from the libc > one for Musl? > > /usr/include/linux/kernel.h has char > _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */ > /usr/include/sys/sysinfo.h has char __reserved[256]; > > glibc just includes the kernel header from sys/sysinfo.h so both these > structs are the same size there, so not sure I see any rationale. I don't think there was any particular rationale; I just did it to make sure there's plenty of space for future expansion. Changing it to match should be fine unless anybody objects. Note however that the glibc definition gives no room to expand on 64-bit. Rich