From owner-svn-src-all@freebsd.org Tue Dec 29 22:51:37 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B82B4A539CB for ; Tue, 29 Dec 2015 22:51:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9773418E6 for ; Tue, 29 Dec 2015 22:51:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 29 Dec 2015 22:50:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBTMpTIj017140; Tue, 29 Dec 2015 15:51:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1451429489.1369.35.camel@freebsd.org> Subject: Re: svn commit: r292809 - head/lib/libc/stdio From: Ian Lepore To: John Baldwin , Warner Losh Cc: src-committers , svn-src-head@freebsd.org, svn-src-all@freebsd.org, Warner Losh Date: Tue, 29 Dec 2015 15:51:29 -0700 In-Reply-To: <2345870.SHMMVrpc1D@ralph.baldwin.cx> References: <201512272304.tBRN4C5D034464@repo.freebsd.org> <41508412.yspAtSoPCD@ralph.baldwin.cx> <2345870.SHMMVrpc1D@ralph.baldwin.cx> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 22:51:37 -0000 On Tue, 2015-12-29 at 11:37 -0800, John Baldwin wrote: > On Monday, December 28, 2015 01:01:26 PM Warner Losh wrote: > > I'll look at that, but I don't think posix_memalign is the right > > way to go. > > The alignment of FILE is more strict than posix_memalign will > > return. Ian's > > idea of __alignof__ is the way to go. We allocate them in one block > > on > > purpose for performance, and posix_memalign would be a one at a > > time affair. > > posix_memalign gives you whatever alignment you ask for. Using > __alignof__ > to determine the alignment instead of hardcoding sizeof(int64_t) > would > certainly be an improvement. If you move the glue after the FILE > objects > then you can use posix_memalign() directly as so: > > void *mem; > int error; > > error = posix_memalign(&mem, MAX(ALIGNBYTES, > __alignof__(mbstate_t)), > n * sizeof(FILE) + sizeof(*g)); > if (error) > return (NULL); > p = (FILE *)mem; > g = (struct glue *)(p + n); > g->next = NULL; > g->niobs = n; > g->iobs = p; > ... > > (This presumes that the requested alignment of 'struct glue' is less > than > the alignment needed by FILE which should be true.) > If there's going to be an assumption that __alignof__(glue) <= __alignof__(FILE), it might be nice to have a static_assert() of that to prevent a future time bomb similar to the one that exploded on arm when it turned out the opposite assumption was wrong. -- Ian