From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5042 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Pawe=C5=82_Dziepak?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] add definition of max_align_t to stddef.h Date: Sun, 4 May 2014 04:36:03 +0200 Message-ID: References: <1398889381-22981-1-git-send-email-pdziepak@quarnos.org> <20140430214250.GI12324@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1399173739 5210 80.91.229.3 (4 May 2014 03:22:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2014 03:22:19 +0000 (UTC) Cc: musl@lists.openwall.com To: Szabolcs Nagy Original-X-From: musl-return-5046-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 04 05:22:09 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 1Wgn0D-0006bF-Er for gllmg-musl@plane.gmane.org; Sun, 04 May 2014 05:22:09 +0200 Original-Received: (qmail 15375 invoked by uid 550); 4 May 2014 03:22:08 -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 22100 invoked from network); 4 May 2014 02:36:15 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eXpR12f2y/VhPI34m/qWKu/V5cciC+qjIPRUoE07giY=; b=lGpj7KuFXhtTXzaPMgPZeFg8y1fqw7a6tsNSDzeyqeDms3b0duKn83RbY943k8iz/T fQHQGvYfCszVXBowqFXmQRB6btiFFunkm6JjiXUFsBVAXmDZ/+fRhuDirkCTDH9GKbsT Rg30kJvexUKQq6oHlXWAt5O1FPgz6NVLB43UmEE2gyZQycSLu+mzQ+gAREvgU7B6a5yK njxqRxW+2P/eM2ezUyjKdErIczq/DFF1tN4Sy1+0LAnNdSbjw6xdK9YJNv+UY5AYCqDs W/Uwc1ijbMhQB5gk2ztces2SMG/An064/JHtSnhQfhAoDDXEyfl7p/nE4TzWnLWsblyq Ckig== X-Gm-Message-State: ALoCoQmW1p9RkXxnHmDDd8I7b2klfuYgXxaef0jvAhgr8/X/ucRVzLlxRDXnT1ravp9FTZl1DRkU X-Received: by 10.50.141.232 with SMTP id rr8mr392786igb.48.1399170963181; Sat, 03 May 2014 19:36:03 -0700 (PDT) In-Reply-To: <20140430214250.GI12324@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:5042 Archived-At: 2014-04-30 23:42 GMT+02:00 Szabolcs Nagy : > * Pawel Dziepak [2014-04-30 22:23:01 +0200]: >> >> +TYPEDEF union { long double ld; long long ll; } max_align_t; > > this is wrong > > - ld and ll identifiers are not reserved for the implementation > (you could name them _ld, _ll or __ld, __ll etc) I will fix that. However, I must admit I don't see why members of the union (or struct) have to use identifiers reserved for the implementation. It's not like they can conflict with anything, isn't it? > and see previous max_align_t discussion > http://www.openwall.com/lists/musl/2014/04/28/8 > > - compiler implementations are non-conforming on some platforms > (_Alignof returns inconsistent results for the same object type so > reasoning about alignments is problematic, there are exceptions > where this is allowed in c++11 but not in c11) > > - max_align_t is part of the abi and your solution is incompatible > with gcc and clang (your definition gives 4 byte _Alignof(max_align_t) > on i386 instead of 8) The behavior of _Alignof on x86 is indeed quite surprising. I actually don't see why 8 is the right value and 4 isn't - System V ABI for x86 doesn't mention any type with alignment 8. Anyway, I agree that it would be a good thing to mach the definition gcc and clang use, i.e. something like that: union max_align_t { alignas(long long) long long _ll; alignas(long double) long double _ld; }; > there is probably not much choice and musl will have to copy the > silly definition used in gcc/clang making max_align_t not very > useful (it does not reflect malloc alignment supported by the libc > nor the object alignments supported by the compiler) Well, alignments supported by the compiler may be different from the alignments supported by the libc and that depends on how the implementation supports extended alignments. max_align_t specifies the greatest fundamental alignment which is guaranteed to be supported in all contexts (i.e. it's at least as strict as the strictest alignment required by fundamental types). Pawe=C5=82