From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) by sourceware.org (Postfix) with ESMTPS id E64D03858C3A for ; Thu, 9 Dec 2021 19:35:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E64D03858C3A Received: by mail-vk1-xa33.google.com with SMTP id h1so4565682vkh.0 for ; Thu, 09 Dec 2021 11:35:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=J9Gv0L73MoUcJp2uFNnfytgymRgYb2zX9Is6ub8yfBk=; b=OkRPT1Xr6YN+qNvNWtZvryVN1rzcYe3H///qDg/UZvqVA9j/lCsQ6dJpCfDxBRkHTY bewRTtZpUyHfAuhcnta82ZdbloSR7+IzQDdMAPQtuJtY5DNpZ0pQ/G0s2u2msEfJkH1i 30mhaR7Wf7f5HEK5U9OR3uEmHDdoXqdfzMMnc42ufZeyFTKxhoUC70gaoJtvJYtDB7Ed onl1vnLmbCvYS7dZ1i+vmgco6StZgL+bkF7E59CAJ9U5rZJEKxIidd0Fws131NO4hZlf K9L9xebzYwSe4dlUiZUVd9oJkBqbz0vMtukFdQ9bPQnfq/xLLfvhkLWYzwql4GKpg5uW ehVQ== X-Gm-Message-State: AOAM532EjDKayf9lZ7r+M//ZiLI6SBjqC6EOXB6mNOImmEnweQEaWOmO LU0UALNUvd8HNl4xJQhDfxsxZXt5gPyDfg== X-Google-Smtp-Source: ABdhPJwHWuebI2zNFeyiu73rivP8f9ZWaj2cef/1Cb5aSQXdKkW/p4S97DySurD8Agek5I4/FOv50w== X-Received: by 2002:a05:6122:64b:: with SMTP id h11mr11406841vkp.16.1639078525452; Thu, 09 Dec 2021 11:35:25 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:a776:7f6e:252c:9def:c66? ([2804:431:c7ca:a776:7f6e:252c:9def:c66]) by smtp.gmail.com with ESMTPSA id e7sm519744vkn.20.2021.12.09.11.35.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Dec 2021 11:35:25 -0800 (PST) Message-ID: <6ab62b15-6982-0786-3b61-b27c058c4475@linaro.org> Date: Thu, 9 Dec 2021 16:35:23 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH] linux: Use 'long int' for timespec tv_nsec on x32 (BZ #16437) Content-Language: en-US To: Florian Weimer , Adhemerval Zanella via Libc-alpha Cc: Zack Weinberg References: <20211209191048.4031643-1-adhemerval.zanella@linaro.org> <87r1alegcp.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87r1alegcp.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-14.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 19:35:28 -0000 On 09/12/2021 16:19, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> diff --git a/time/bits/types/struct_timespec.h b/time/bits/types/struct_timespec.h >> index 489e81136d..b962d3f95f 100644 >> --- a/time/bits/types/struct_timespec.h >> +++ b/time/bits/types/struct_timespec.h >> @@ -15,19 +15,9 @@ struct timespec >> #else >> __time_t tv_sec; /* Seconds. */ >> #endif >> -#if __WORDSIZE == 64 \ >> - || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \ >> - || (__TIMESIZE == 32 && !defined __USE_TIME_BITS64) >> - __syscall_slong_t tv_nsec; /* Nanoseconds. */ >> -#else >> -# if __BYTE_ORDER == __BIG_ENDIAN >> - int: 32; /* Padding. */ >> - long int tv_nsec; /* Nanoseconds. */ >> -# else >> - long int tv_nsec; /* Nanoseconds. */ >> - int: 32; /* Padding. */ >> -# endif >> -#endif >> + int : 8 * (sizeof (time_t) - sizeof (long)) * (__BYTE_ORDER == __BIG_ENDIAN); >> + long int tv_nsec; >> + int : 8 * (sizeof (time_t) - sizeof (long)) * (__BYTE_ORDER == __LITTLE_ENDIAN); >> }; > > I think zero-width bitfields are problematic from an ABI perspective: > > zero width bitfields and ABIs > Sigh... so each backend now might have a different behavior. Alright, we can use Zack's suggestion then: diff --git a/time/bits/types/struct_timespec.h b/time/bits/types/struct_timespec.h index b962d3f95f..a93100b0dd 100644 --- a/time/bits/types/struct_timespec.h +++ b/time/bits/types/struct_timespec.h @@ -15,9 +15,15 @@ struct timespec #else __time_t tv_sec; /* Seconds. */ #endif - int : 8 * (sizeof (time_t) - sizeof (long)) * (__BYTE_ORDER == __BIG_ENDIAN); - long int tv_nsec; - int : 8 * (sizeof (time_t) - sizeof (long)) * (__BYTE_ORDER == __LITTLE_ENDIAN); +#if __WORDSIZE == 32 && (__TIMESIZE == 64 || defined __USE_TIME_BITS64) \ + && __BYTE_ORDER == __BIG_ENDIAN + int: 32; /* Padding. */ +#endif + long int tv_nsec; /* Nanoseconds. */ +#if __WORDSIZE == 32 && (__TIMESIZE == 64 || defined __USE_TIME_BITS64) \ + && __BYTE_ORDER == __LITTLE_ENDIAN + int: 32; /* Padding. */ +#endif }; #endif > > The change is also not entirely ABI-compatible because existing code on > x32 depends on the implementation clearing the upper 32 bits, and if new > code copies around structs, it won't necessary copy the zero bits. Afaiu the high-bits clearing is strictly necessary on kABI boundary for set functions. Some issues indeed might arise if user use timespec embedded in some function and mix objects built with different glibc version, but it is similar to 32-bit architectures with mixing time_t objects.