From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B1C7D3858CDB; Wed, 20 Mar 2024 12:27:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1C7D3858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710937662; bh=OdR1vWn2ffiVy1c05AWgrbUKYpc6+Cv3aWpmRZTmFxU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=p1zrT3jhVwi50cDj3fhVPqieh26DTp3V28KYkUUs7QFSWShdCxa1PiQ54Zg5efoJW G4IrmBiDQdMr/xs22uT5q227WT3w3//nZYtdmYLTUXCdqGD4b7/KXbeDpP5YKSsUSY 8YZfUaC76du6AwZynvvmzy2V6mo9RCGNv0s5PgJA= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug time/31510] Wrong type for timeval.tv_usec on 32-bit archs with _TIME_BITS=64 Date: Wed, 20 Mar 2024 12:27:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: time X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31510 --- Comment #4 from Adhemerval Zanella --- (In reply to Joseph Myers from comment #2) > Shouldn't we fix how suseconds_t is defined in glibc in the 64-bit time > case? It's not as if any interfaces in glibc use suseconds_t other than as > part of struct timeval (though we should still warn in NEWS about potenti= al > compatibility issues for any interfaces using suseconds_t in third-party > libraries). That's why I am not fully sure which would be the best way, since this stri= ctly is an ABI break.=20=20 At least using the timespec trick to keep the type as currently defined sho= uld not cause any issue (since the type holds all potential values), and it sho= uld be back-portable. --=20 You are receiving this mail because: You are on the CC list for the bug.=