From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 25F1621D12 for ; Sun, 21 Apr 2024 05:51:50 +0200 (CEST) Received: (qmail 25674 invoked by uid 550); 21 Apr 2024 03:51:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25639 invoked from network); 21 Apr 2024 03:51:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney.org; s=google; t=1713671497; x=1714276297; darn=lists.openwall.com; h=user-agent:message-id:from:subject:to:date:from:to:cc:subject:date :message-id:reply-to; bh=mUJqIB8sCJrhRtu/zUMqaUAEacVGGEhfIGb4gsGxYeI=; b=giheOteWD02SdkVT115Vao+AJIbe+KvkzfD0nGBLMvwBIfBU62fSLaPTEOV/AWkMaA Us+70Hn4pFUpASbKvQw/pagX5TbWoCQp+Pcv5mvcXGLOV+QiOgl+0IvRO0pQ7TYnuF90 PHDdi0NpSe/K5oBUlZMQUIg3P58ClyNW3+FvuFYximAY3QA7VO0mQvGH6fmlf9rwIDHu DpokMBOupx/w4AbR2KsrufE2dAwydMCA9Vo9pL0KfEIdwtr83T3p4HwT7570hQf+P9wq qrlxMCAqgpH/dkbAOddP3mlKfutogLchYr3dAvc8X+m6zL95TEwgvtiSmzvfdO7kAs+5 0kGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713671497; x=1714276297; h=user-agent:message-id:from:subject:to:date:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mUJqIB8sCJrhRtu/zUMqaUAEacVGGEhfIGb4gsGxYeI=; b=O3gaHMVyaMKKjkszCB6aUIOQs0lr34u2IDeIE7Mvb+C5h1PtS+LSl5Wq5SB6EunrVI l2KbpZtX8C0yd4iT2Xnlsx75ogO/PtYthOnFH32MNQl8cvF8yjUHa5dKYJu8VNjSXBDS s9r7ResSgq2/2BO+cL+u+5dIFIGwHPLzRqj/HRaQs3Tr/mFj713y2stIBc2Gt+IJVMsU W4cTzHVUtdWGmVP9MiKMnim1V/9F7j3wLZPT4WAdyDOxUY0u350dWJBQJX4L0YWlWymG 1zT9bJNZDqMyrFTgUJ82znLFIsHaLEP4M0EVild2Qulzs4+UrNKh0xinIecICXR297FU uD4g== X-Gm-Message-State: AOJu0YyK5XO2R3Hqb+dXns2R9oAlMWb/Y+6419szMvtqLQg4gU24F/fi B8ksoHlZfi6Aeozq5NtxnEMs0uiflaJuXW9k+Jtc/iSaWwIMZWvKrikLRD4KylGorwD1XTBGupl JB+4= X-Google-Smtp-Source: AGHT+IHtyTP1duCafunu4KCKZyzcLr8tBIEjvml5w6nxN1aOBax4eTfUn9jej4ZszlzSFs8HWYmbWQ== X-Received: by 2002:a05:6a21:6711:b0:1ac:e02b:5cdd with SMTP id wh17-20020a056a21671100b001ace02b5cddmr4893899pzb.7.1713671496667; Sat, 20 Apr 2024 20:51:36 -0700 (PDT) Date: Sat, 20 Apr 2024 20:51:35 -0700 To: musl@lists.openwall.com From: Michael Forney Message-Id: <3KDMGHI91MHTL.24XCHF6E4X1XG@mforney.org> User-Agent: mblaze/1.2 Subject: [musl] Alignment attribute in headers I'm looking at changing headers to use C11 alignment specifiers when available instead of GNU attributes. These are used in the following headers: arch/loongarch64/bits/signal.h arch/powerpc/bits/signal.h arch/powerpc/bits/user.h arch/powerpc64/bits/signal.h arch/powerpc64/bits/user.h arch/riscv32/bits/signal.h arch/riscv64/bits/signal.h arch/x32/bits/shm.h In some of these cases (powerpc, powerpc64, x32), the attribute is conditional on __GNUC__, which I think may result in improperly aligned structs on compilers that don't define this. For powerpc/powerpc64 user.h, the attribute is applied to a typedef of a struct, but alignas can't be used with typedef. I think this could be fixed by moving the attribute/alignment specifier to the first (and only) struct member instead. Similarly, x32 shm.h uses an attribute after a struct specifier, which could be made compatible with an alignment specifier in the same way. I also noticed that arch/i386/bits/alltypes.h.in uses _Alignas(8) for C, __attribute__((__aligned__(8))) for GNU C++, and alignas(8) for non-GNU C++. Looking through commit history, this seems to be a work around for a gcc 4.7 bug which claims C++11 support but doesn't offer alignas. Do we need to use this same approach for each of the instances above to handle the three cases (C, GNU C++, non-GNU C++)? I see that stdalign.h uses _Alignas conditional on C11 support, but i386 alltypes.h uses it unconditionally on C. Should i386 alltypes.h use __attribute__ when __STDC_VERSION__ < 201112L? Something like #if __STDC_VERSION__ >= 201112L /* use _Alignas */ #elif defined(__cplusplus) && !defined(__GNUC__) /* use alignas */ #else /* use __attribute__((__aligned__(N))) */ #end ?