From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dalias@libc.org>
Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13])
 by sourceware.org (Postfix) with ESMTPS id 7BEA43858C27
 for <libc-alpha@sourceware.org>; Thu,  9 Dec 2021 20:17:18 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BEA43858C27
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=libc.org
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org
Date: Thu, 9 Dec 2021 15:17:17 -0500
From: Rich Felker <dalias@libc.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
 Adhemerval Zanella <adhemerval.zanella@linaro.org>,
 "'Alejandro Colomar (man-pages)'" <alx.manpages@gmail.com>,
 Stefan Puiu <stefan.puiu@gmail.com>,
 Andreas Schwab <schwab@linux-m68k.org>,
 Michael Kerrisk <mtk.manpages@gmail.com>,
 =?utf-8?B?0L3QsNCx?= <nabijaczleweli@nabijaczleweli.xyz>,
 Jakub Wilk <jwilk@jwilk.net>, libc-alpha@sourceware.org,
 Zack Weinberg <zack@owlfolio.org>
Subject: Re: [RFC v3 3/3] sys/types.h: Make snseconds_t user visible
Message-ID: <20211209201717.GA7074@brightrain.aerifal.cx>
References: <20211207111957.8087-1-alx.manpages@gmail.com>
 <20211208144757.37641-3-alx.manpages@gmail.com>
 <3a15b008-3173-018b-121b-4aeb817e378a@cs.ucla.edu>
 <20211208182506.GY7074@brightrain.aerifal.cx>
 <433b1982-f68a-402f-b89b-ed39d56b513e@www.fastmail.com>
 <3946d7a9-48cd-32bf-06dc-129181bdd8e7@linaro.org>
 <f2b14bea-59ac-64b1-76ec-10153ad02ef6@cs.ucla.edu>
 <alpine.DEB.2.22.394.2112092012230.72995@digraph.polyomino.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2112092012230.72995@digraph.polyomino.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2021 20:17:20 -0000

On Thu, Dec 09, 2021 at 08:13:53PM +0000, Joseph Myers wrote:
> On Thu, 9 Dec 2021, Paul Eggert wrote:
> 
> > Nice idea, and we can simplify things more: we don't need that last line as
> > the compiler will insert that padding for us on all glibc platforms that need
> > it. Also, the code should use 'long int' consistently. Further, there's no
> 
> On 32-bit x86, with _TIME_BITS=64, the structure is meant to have trailing 
> padding, but won't unless it's explicit (the alignment of long long in 
> structures is 4 bytes).

To be clear: omitting the explicit padding here would be an ABI break
*and* a buffer overflow, since the kernel will write 16 bytes but the
struct would only be 12 bytes. Thus the explicit padding is mandatory.

At least x86 (32-bit) and m68k are affected. I think there are a few
other obscure archs without 8-byte alignment (maybe or1k or
microblaze?) that might be too but I'm not sure of whether any of them
are supported by glibc.

Rich