From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5207 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Revisiting max_align_t and stdalign.h Date: Sun, 8 Jun 2014 11:54:41 -0400 Message-ID: <20140608155441.GG179@brightrain.aerifal.cx> References: <20140608145924.GA19121@brightrain.aerifal.cx> 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 1402242901 4599 80.91.229.3 (8 Jun 2014 15:55:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Jun 2014 15:55:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5212-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 08 17:54:55 2014 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 1WtfQs-0000KJ-Qa for gllmg-musl@plane.gmane.org; Sun, 08 Jun 2014 17:54:54 +0200 Original-Received: (qmail 12271 invoked by uid 550); 8 Jun 2014 15:54:53 -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 12263 invoked from network); 8 Jun 2014 15:54:53 -0000 Content-Disposition: inline In-Reply-To: <20140608145924.GA19121@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5207 Archived-At: On Sun, Jun 08, 2014 at 10:59:24AM -0400, Rich Felker wrote: > I was looking back at the max_align_t issue and there seems to be a > lot more to resolve: gcc is badly broken in regards to everything > related to stdalign.h. This test program on i386: > > #include > #include > > int main() > { > long long x; > printf("%d %d\n", (int)_Alignof(x), (int)_Alignof(long long)); > } > > prints 8 8 on most gcc versions, and what's worse, its behavior > depends on -std; adding -std=c11 and using gcc 4.9.0 changes it to > printing 8 4. The correct result of course would be 4 4. My tests must have been messed up here; apparently gcc 4.9.0 works even without -std=c11. So a workaround that applies only to versions earlier than 4.9 should be possible. Moreover it appears that _Alignof is not required to accept expressions as its argument, only types. If this is correct then 4.9.0 is working, albeit doing something ugly in the case of invalid code. > I had in mind the following patch for stdalign.h: > > diff --git a/include/stdalign.h b/include/stdalign.h > index b6e50ae..3f00466 100644 > --- a/include/stdalign.h > +++ b/include/stdalign.h > @@ -4,7 +4,7 @@ > /* this whole header only works in C11 or with compiler extensions */ > #if __STDC_VERSION__ < 201112L && defined( __GNUC__) > #define _Alignas(t) __attribute__((__aligned__(t))) > -#define _Alignof(t) __alignof__(t) > +#define _Alignof(t) (sizeof(struct {char __x; __typeof__(t) __y;}) - sizeof(t)) > #endif > > #define alignas _Alignas > > but it doesn't really help since _Alignof is broken even with > -std=c11. > > I suspect _Alignas is similarly broken. And _Alignas might be broken even on current gcc -- it accepts not just types but also expressions. However it's not clear to me whether it can even be used in contexts where it would be observably wrong, so I don;t know how to write a test for it. IIRC there's an open issue about whether it can be used in structs, or only on objects. Rich