[v12,1/3] Y2038: provide size of default time_t for target architecture
Commit Message
To determine whether the default time_t interfaces are 32-bit
and so need conversions, or are 64-bit and so are compatible
with the internal 64-bit type without conversions, a macro
giving the size of the default time_t is also required.
This macro is called __TIMESIZE.
This macro can then be used instead of __WORDSIZE in msq-pad.h
and shm-pad.h files, which in turn allows removing their x86
variants, and in sem-pad.h files but keeping the x86 variant.
This patch was tested by running 'make check' on branch master
then applying this patch and running 'make check' again, and
checking that both 'make check' yield identical results.
This was done on x86_64-linux-gnu and i686-linux-gnu.
* bits/timesize.h: New file.
* stdlib/Makefile (headers): Add bits/timesize.h.
* sysdeps/unix/sysv/linux/bits/msq-pad.h: Replace __WORDSIZE with __TIMESIZE.
* sysdeps/unix/sysv/linux/bits/sem-pad.h: Likewise.
* sysdeps/unix/sysv/linux/bits/shm-pad.h: Likewise.
* sysdeps/unix/sysv/linux/hppa/bits/msq-pad.h: Likewise.
* sysdeps/unix/sysv/linux/hppa/bits/sem-pad.h: Likewise.
* sysdeps/unix/sysv/linux/hppa/bits/shm-pad.h: Likewise.
* sysdeps/unix/sysv/linux/mips/bits/msq-pad.h: Likewise.
* sysdeps/unix/sysv/linux/powerpc/bits/msq-pad.h: Likewise.
* sysdeps/unix/sysv/linux/powerpc/bits/sem-pad.h: Likewise.
* sysdeps/unix/sysv/linux/powerpc/bits/shm-pad.h: Likewise.
* sysdeps/unix/sysv/linux/sparc/bits/msq-pad.h: Likewise.
* sysdeps/unix/sysv/linux/sparc/bits/sem-pad.h: Likewise.
* sysdeps/unix/sysv/linux/sparc/bits/shm-pad.h: Likewise.
* sysdeps/unix/sysv/linux/x86/bits/msq-pad.h: Delete file.
* sysdeps/unix/sysv/linux/x86/bits/shm-pad.h: Likewise.
* sysdeps/unix/sysv/linux/x86/bits/timesize.h: New file.
---
.../linux/x86/bits/shm-pad.h => bits/timesize.h | 16 ++++------------
stdlib/Makefile | 2 +-
sysdeps/unix/sysv/linux/bits/msq-pad.h | 4 ++--
sysdeps/unix/sysv/linux/bits/sem-pad.h | 4 ++--
sysdeps/unix/sysv/linux/bits/shm-pad.h | 4 ++--
sysdeps/unix/sysv/linux/hppa/bits/msq-pad.h | 4 ++--
sysdeps/unix/sysv/linux/hppa/bits/sem-pad.h | 4 ++--
sysdeps/unix/sysv/linux/hppa/bits/shm-pad.h | 6 +++---
sysdeps/unix/sysv/linux/mips/bits/msq-pad.h | 6 +++---
sysdeps/unix/sysv/linux/powerpc/bits/msq-pad.h | 4 ++--
sysdeps/unix/sysv/linux/powerpc/bits/sem-pad.h | 4 ++--
sysdeps/unix/sysv/linux/powerpc/bits/shm-pad.h | 6 +++---
sysdeps/unix/sysv/linux/sparc/bits/msq-pad.h | 4 ++--
sysdeps/unix/sysv/linux/sparc/bits/sem-pad.h | 4 ++--
sysdeps/unix/sysv/linux/sparc/bits/shm-pad.h | 4 ++--
.../linux/x86/bits/{msq-pad.h => timesize.h} | 15 ++++++---------
16 files changed, 40 insertions(+), 51 deletions(-)
rename sysdeps/unix/sysv/linux/x86/bits/shm-pad.h => bits/timesize.h (68%)
rename sysdeps/unix/sysv/linux/x86/bits/{msq-pad.h => timesize.h} (74%)
Comments
How does this patch differ from version 11, which I already approved?
When a patch is approved that does not depend on other unapproved patches,
the general expectation is that it will be committed, unless you find some
other issue with it so you no longer think it's suitable for commit as-is
and instead want to propose a new changed version. Then a shorter patch
series would be posted, omitting the committed patches.
In general, when submitting a revised patch or patch series it's a good
idea to make clear what has changed from the previous version (this should
go in the patch submission emails, but not the commit message; the Linux
kernel convention is that after the commit message you can have a "---"
line, then any additional information not intended for the commit message,
such as about changes from previous patch versions, before the patch
itself).
Hi Joseph,
On Mon, 22 Oct 2018 14:40:24 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> How does this patch differ from version 11, which I already approved?
>
> When a patch is approved that does not depend on other unapproved patches,
> the general expectation is that it will be committed, unless you find some
> other issue with it so you no longer think it's suitable for commit as-is
> and instead want to propose a new changed version. Then a shorter patch
> series would be posted, omitting the committed patches.
My bad - I'm used to resubmitting series entirely even when only some
patches need fixing. I'll omit OK'd patches from now on.
> In general, when submitting a revised patch or patch series it's a good
> idea to make clear what has changed from the previous version (this should
> go in the patch submission emails, but not the commit message; the Linux
> kernel convention is that after the commit message you can have a "---"
> line, then any additional information not intended for the commit message,
> such as about changes from previous patch versions, before the patch
> itself).
I'll add patch history when applicable.
Cordialement,
Albert ARIBAUD
3ADEV
On Mon, 22 Oct 2018, Albert ARIBAUD wrote:
> > When a patch is approved that does not depend on other unapproved patches,
> > the general expectation is that it will be committed, unless you find some
> > other issue with it so you no longer think it's suitable for commit as-is
> > and instead want to propose a new changed version. Then a shorter patch
> > series would be posted, omitting the committed patches.
>
> My bad - I'm used to resubmitting series entirely even when only some
> patches need fixing. I'll omit OK'd patches from now on.
You need to *commit* the approved patches to master, and then send a
series that applies to current master with the approved patches included.
If a patch can't be committed because it depends on an earlier unapproved
patch (or because the approval was explicitly conditional on a whole
series going in at once), then it's appropriate still to include it in the
series, but to state explicitly that it's been approved and is unchanged
from the approved version (if that's the case).
On Mon, 22 Oct 2018, Joseph Myers wrote:
> You need to *commit* the approved patches to master, and then send a
To be clear: my expectation, after approving patch 1/3, version 11, was
that the next steps would be: (a) commit patch 1 to master and push that
commit; (b) send a series that contains only two patches, where patch 1/2
applies cleanly to master and patch 2/2 applies to (master + patch 1/2).
Hi Joseph,
On Mon, 22 Oct 2018 21:44:38 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :
> On Mon, 22 Oct 2018, Albert ARIBAUD wrote:
>
> > > When a patch is approved that does not depend on other unapproved patches,
> > > the general expectation is that it will be committed, unless you find some
> > > other issue with it so you no longer think it's suitable for commit as-is
> > > and instead want to propose a new changed version. Then a shorter patch
> > > series would be posted, omitting the committed patches.
> >
> > My bad - I'm used to resubmitting series entirely even when only some
> > patches need fixing. I'll omit OK'd patches from now on.
>
> You need to *commit* the approved patches to master, and then send a
> series that applies to current master with the approved patches included.
> If a patch can't be committed because it depends on an earlier unapproved
> patch (or because the approval was explicitly conditional on a whole
> series going in at once), then it's appropriate still to include it in the
> series, but to state explicitly that it's been approved and is unchanged
> from the approved version (if that's the case).
Just to make sure: when you say "you need to commit the approved
patches to master", are you saying that I am in capacity to commit to
branch master of the official glibc repository, and that after your
OK'ing of commit 1/3 of this series, I should now commit this patch to
branch master of glibc myself?
I'm genuinely surprised that the glibc project would allow this, but if
that's how it works, then fine.
Cordialement,
Albert ARIBAUD
3ADEV
On Mon, 22 Oct 2018, Albert ARIBAUD wrote:
> Just to make sure: when you say "you need to commit the approved
> patches to master", are you saying that I am in capacity to commit to
> branch master of the official glibc repository, and that after your
> OK'ing of commit 1/3 of this series, I should now commit this patch to
> branch master of glibc myself?
Yes.
https://sourceware.org/glibc/wiki/Committer%20checklist
(In this case, no NEWS or Bugzilla updates are needed, but you do need to
make sure to update ChangeLog appropriately.)
* Albert ARIBAUD:
> Hi Joseph,
>
> On Mon, 22 Oct 2018 21:44:38 +0000, Joseph Myers
> <joseph@codesourcery.com> wrote :
>
>> On Mon, 22 Oct 2018, Albert ARIBAUD wrote:
>>
>> > > When a patch is approved that does not depend on other unapproved patches,
>> > > the general expectation is that it will be committed, unless you find some
>> > > other issue with it so you no longer think it's suitable for commit as-is
>> > > and instead want to propose a new changed version. Then a shorter patch
>> > > series would be posted, omitting the committed patches.
>> >
>> > My bad - I'm used to resubmitting series entirely even when only some
>> > patches need fixing. I'll omit OK'd patches from now on.
>>
>> You need to *commit* the approved patches to master, and then send a
>> series that applies to current master with the approved patches included.
>> If a patch can't be committed because it depends on an earlier unapproved
>> patch (or because the approval was explicitly conditional on a whole
>> series going in at once), then it's appropriate still to include it in the
>> series, but to state explicitly that it's been approved and is unchanged
>> from the approved version (if that's the case).
>
> Just to make sure: when you say "you need to commit the approved
> patches to master", are you saying that I am in capacity to commit to
> branch master of the official glibc repository, and that after your
> OK'ing of commit 1/3 of this series, I should now commit this patch to
> branch master of glibc myself?
>
> I'm genuinely surprised that the glibc project would allow this, but if
> that's how it works, then fine.
If you still have doubts about the commit message or the ChangeLog
entry, I'm happy to review it for you prior to making the change
official.
Thanks,
Florian
Hi Florian,
Le Tue, 23 Oct 2018 11:14:24 +0200, Florian Weimer <fweimer@redhat.com>
a écrit :
> If you still have doubts about the commit message or the ChangeLog
> entry, I'm happy to review it for you prior to making the change
> official.
Thanks. I have prepared my master branch locally, and pushed it on the
glibc repo as the branch aaribaud/master for you to have a look at.
Right now, I am running a fast make check as per the checklist.
> Thanks,
> Florian
Cordialement,
Albert ARIBAUD
3ADEV
* Albert ARIBAUD:
> Hi Florian,
>
> Le Tue, 23 Oct 2018 11:14:24 +0200, Florian Weimer <fweimer@redhat.com>
> a écrit :
>
>> If you still have doubts about the commit message or the ChangeLog
>> entry, I'm happy to review it for you prior to making the change
>> official.
>
> Thanks. I have prepared my master branch locally, and pushed it on the
> glibc repo as the branch aaribaud/master for you to have a look at.
> Right now, I am running a fast make check as per the checklist.
I think the ChangeLog should list the names of macros being changed, so
something like thiss:
* sysdeps/unix/sysv/linux/mips/bits/msq-pad.h
(__MSQ_PAD_AFTER_TIME, __SHM_PAD_BETWEEN_TIME_AND_SEGSZ): Use
__TIMESIZE instead of __WORDSIZE.
Otherwise, looks good.
Thanks,
Florian
Hi Florian,
On Wed, 24 Oct 2018 10:01:04 +0200, Florian Weimer <fweimer@redhat.com>
wrote :
> * Albert ARIBAUD:
>
> > Hi Florian,
> >
> > Le Tue, 23 Oct 2018 11:14:24 +0200, Florian Weimer <fweimer@redhat.com>
> > a écrit :
> >
> >> If you still have doubts about the commit message or the ChangeLog
> >> entry, I'm happy to review it for you prior to making the change
> >> official.
> >
> > Thanks. I have prepared my master branch locally, and pushed it on the
> > glibc repo as the branch aaribaud/master for you to have a look at.
> > Right now, I am running a fast make check as per the checklist.
>
> I think the ChangeLog should list the names of macros being changed, so
> something like thiss:
>
> * sysdeps/unix/sysv/linux/mips/bits/msq-pad.h
> (__MSQ_PAD_AFTER_TIME, __SHM_PAD_BETWEEN_TIME_AND_SEGSZ): Use
> __TIMESIZE instead of __WORDSIZE.
Thanks, I've rewritten the ChangeLog file (and the commit message
changelog part for homogeneity) based on your example -- listing the
right macro(s) for each header file of course.
> Otherwise, looks good.
Thanks for your review.
> Thanks,
> Florian
Cordialement,
Albert ARIBAUD
3ADEV
* Albert ARIBAUD:
> Hi Florian,
>
> On Wed, 24 Oct 2018 10:01:04 +0200, Florian Weimer <fweimer@redhat.com>
> wrote :
>
>> * Albert ARIBAUD:
>>
>> > Hi Florian,
>> >
>> > Le Tue, 23 Oct 2018 11:14:24 +0200, Florian Weimer <fweimer@redhat.com>
>> > a écrit :
>> >
>> >> If you still have doubts about the commit message or the ChangeLog
>> >> entry, I'm happy to review it for you prior to making the change
>> >> official.
>> >
>> > Thanks. I have prepared my master branch locally, and pushed it on the
>> > glibc repo as the branch aaribaud/master for you to have a look at.
>> > Right now, I am running a fast make check as per the checklist.
>>
>> I think the ChangeLog should list the names of macros being changed, so
>> something like thiss:
>>
>> * sysdeps/unix/sysv/linux/mips/bits/msq-pad.h
>> (__MSQ_PAD_AFTER_TIME, __SHM_PAD_BETWEEN_TIME_AND_SEGSZ): Use
>> __TIMESIZE instead of __WORDSIZE.
>
> Thanks, I've rewritten the ChangeLog file (and the commit message
> changelog part for homogeneity) based on your example -- listing the
> right macro(s) for each header file of course.
Please update the data in the ChangeLog and the commit (git commit
--amend --date="`date`"), rebase to current master, and then you should
be okay to push to the official master branch.
(I assume this patch has actually been reviewed, I have not checked
that. 8-)
Thanks,
Florian
Hi Florian,
On Wed, 24 Oct 2018 11:24:25 +0200, Florian Weimer <fweimer@redhat.com>
wrote :
> * Albert ARIBAUD:
>
> > Hi Florian,
> >
> > On Wed, 24 Oct 2018 10:01:04 +0200, Florian Weimer <fweimer@redhat.com>
> > wrote :
> >
> >> * Albert ARIBAUD:
> >>
> [...]
> [...]
> [...]
> >>
> >> I think the ChangeLog should list the names of macros being changed, so
> >> something like thiss:
> >>
> >> * sysdeps/unix/sysv/linux/mips/bits/msq-pad.h
> >> (__MSQ_PAD_AFTER_TIME, __SHM_PAD_BETWEEN_TIME_AND_SEGSZ): Use
> >> __TIMESIZE instead of __WORDSIZE.
> >
> > Thanks, I've rewritten the ChangeLog file (and the commit message
> > changelog part for homogeneity) based on your example -- listing the
> > right macro(s) for each header file of course.
>
> Please update the data in the ChangeLog and the commit (git commit
> --amend --date="`date`"), rebase to current master, and then you should
> be okay to push to the official master branch.
Ok.
> (I assume this patch has actually been reviewed, I have not checked
> that. 8-)
Yes it has. :)
> Thanks,
> Florian
Cordialement,
Albert ARIBAUD
3ADEV
similarity index 68%
rename from sysdeps/unix/sysv/linux/x86/bits/shm-pad.h
rename to bits/timesize.h
@@ -1,4 +1,4 @@
-/* Define where padding goes in struct shmid_ds. x86 version.
+/* Bit size of the time_t type at glibc build time, general case.
Copyright (C) 2018 Free Software Foundation, Inc.
This file is part of the GNU C Library.
@@ -16,15 +16,7 @@
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
-#ifndef _SYS_SHM_H
-# error "Never use <bits/shm-pad.h> directly; include <sys/shm.h> instead."
-#endif
+#include <bits/wordsize.h>
-#ifdef __x86_64__
-# define __SHM_PAD_AFTER_TIME 0
-#else
-# define __SHM_PAD_AFTER_TIME 1
-#endif
-#define __SHM_PAD_BEFORE_TIME 0
-#define __SHM_SEGSZ_AFTER_TIME 0
-#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ 0
+/* Size in bits of the 'time_t' type of the default ABI. */
+#define __TIMESIZE __WORDSIZE
@@ -24,7 +24,7 @@ include ../Makeconfig
headers := stdlib.h bits/stdlib.h bits/stdlib-ldbl.h bits/stdlib-float.h \
monetary.h bits/monetary-ldbl.h \
- inttypes.h stdint.h bits/wordsize.h \
+ inttypes.h stdint.h bits/wordsize.h bits/timesize.h \
errno.h sys/errno.h bits/errno.h bits/types/error_t.h \
ucontext.h sys/ucontext.h bits/indirect-return.h \
alloca.h fmtmsg.h \
@@ -20,12 +20,12 @@
# error "Never use <bits/msq-pad.h> directly; include <sys/msg.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
/* On most architectures, padding goes after time fields for 32-bit
systems and is omitted for 64-bit systems. Some architectures pad
before time fields instead, or omit padding despite being
32-bit. */
-#define __MSQ_PAD_AFTER_TIME (__WORDSIZE == 32)
+#define __MSQ_PAD_AFTER_TIME (__TIMESIZE == 32)
#define __MSQ_PAD_BEFORE_TIME 0
@@ -20,7 +20,7 @@
# error "Never use <bits/sem-pad.h> directly; include <sys/sem.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
/* On most architectures, padding goes after time fields for 32-bit
systems and is omitted for 64-bit systems. Some architectures pad
@@ -29,5 +29,5 @@
used for struct semid64_ds in <asm/sembuf.h>, as glibc does not do
layout conversions for this structure. */
-#define __SEM_PAD_AFTER_TIME (__WORDSIZE == 32)
+#define __SEM_PAD_AFTER_TIME (__TIMESIZE == 32)
#define __SEM_PAD_BEFORE_TIME 0
@@ -20,7 +20,7 @@
# error "Never use <bits/shm-pad.h> directly; include <sys/shm.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
/* On most architectures, padding goes after time fields for 32-bit
systems and is omitted for 64-bit systems. Some architectures pad
@@ -31,7 +31,7 @@
layout used for struct shmid64_ds in <asm/shmbuf.h>, as glibc does
not do layout conversions for this structure. */
-#define __SHM_PAD_AFTER_TIME (__WORDSIZE == 32)
+#define __SHM_PAD_AFTER_TIME (__TIMESIZE == 32)
#define __SHM_PAD_BEFORE_TIME 0
#define __SHM_SEGSZ_AFTER_TIME 0
#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ 0
@@ -20,7 +20,7 @@
# error "Never use <bits/msq-pad.h> directly; include <sys/msg.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __MSQ_PAD_AFTER_TIME 0
-#define __MSQ_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __MSQ_PAD_BEFORE_TIME (__TIMESIZE == 32)
@@ -20,7 +20,7 @@
# error "Never use <bits/sem-pad.h> directly; include <sys/sem.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __SEM_PAD_AFTER_TIME 0
-#define __SEM_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __SEM_PAD_BEFORE_TIME (__TIMESIZE == 32)
@@ -20,9 +20,9 @@
# error "Never use <bits/shm-pad.h> directly; include <sys/shm.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __SHM_PAD_AFTER_TIME 0
-#define __SHM_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __SHM_PAD_BEFORE_TIME (__TIMESIZE == 32)
#define __SHM_SEGSZ_AFTER_TIME 1
-#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ (__WORDSIZE == 32)
+#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ (__TIMESIZE == 32)
@@ -20,12 +20,12 @@
# error "Never use <bits/msq-pad.h> directly; include <sys/msg.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#ifdef __MIPSEL__
-# define __MSQ_PAD_AFTER_TIME (__WORDSIZE == 32)
+# define __MSQ_PAD_AFTER_TIME (__TIMESIZE == 32)
# define __MSQ_PAD_BEFORE_TIME 0
#else
# define __MSQ_PAD_AFTER_TIME 0
-# define __MSQ_PAD_BEFORE_TIME (__WORDSIZE == 32)
+# define __MSQ_PAD_BEFORE_TIME (__TIMESIZE == 32)
#endif
@@ -20,7 +20,7 @@
# error "Never use <bits/msq-pad.h> directly; include <sys/msg.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __MSQ_PAD_AFTER_TIME 0
-#define __MSQ_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __MSQ_PAD_BEFORE_TIME (__TIMESIZE == 32)
@@ -20,7 +20,7 @@
# error "Never use <bits/sem-pad.h> directly; include <sys/sem.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __SEM_PAD_AFTER_TIME 0
-#define __SEM_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __SEM_PAD_BEFORE_TIME (__TIMESIZE == 32)
@@ -20,9 +20,9 @@
# error "Never use <bits/shm-pad.h> directly; include <sys/shm.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __SHM_PAD_AFTER_TIME 0
-#define __SHM_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __SHM_PAD_BEFORE_TIME (__TIMESIZE == 32)
#define __SHM_SEGSZ_AFTER_TIME 1
-#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ (__WORDSIZE == 32)
+#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ (__TIMESIZE == 32)
@@ -20,7 +20,7 @@
# error "Never use <bits/msq-pad.h> directly; include <sys/msg.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __MSQ_PAD_AFTER_TIME 0
-#define __MSQ_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __MSQ_PAD_BEFORE_TIME (__TIMESIZE == 32)
@@ -20,7 +20,7 @@
# error "Never use <bits/sem-pad.h> directly; include <sys/sem.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __SEM_PAD_AFTER_TIME 0
-#define __SEM_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __SEM_PAD_BEFORE_TIME (__TIMESIZE == 32)
@@ -20,9 +20,9 @@
# error "Never use <bits/shm-pad.h> directly; include <sys/shm.h> instead."
#endif
-#include <bits/wordsize.h>
+#include <bits/timesize.h>
#define __SHM_PAD_AFTER_TIME 0
-#define __SHM_PAD_BEFORE_TIME (__WORDSIZE == 32)
+#define __SHM_PAD_BEFORE_TIME (__TIMESIZE == 32)
#define __SHM_SEGSZ_AFTER_TIME 1
#define __SHM_PAD_BETWEEN_TIME_AND_SEGSZ 0
similarity index 74%
rename from sysdeps/unix/sysv/linux/x86/bits/msq-pad.h
rename to sysdeps/unix/sysv/linux/x86/bits/timesize.h
@@ -1,4 +1,4 @@
-/* Define where padding goes in struct msqid_ds. x86 version.
+/* Bit size of the time_t type at glibc build time, x86-64 and x32 case.
Copyright (C) 2018 Free Software Foundation, Inc.
This file is part of the GNU C Library.
@@ -16,13 +16,10 @@
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
-#ifndef _SYS_MSG_H
-# error "Never use <bits/msq-pad.h> directly; include <sys/msg.h> instead."
-#endif
-
-#ifdef __x86_64__
-# define __MSQ_PAD_AFTER_TIME 0
+#if defined __x86_64__ && defined __ILP32__
+/* For x32, time is 64-bit even though word size is 32-bit. */
+# define __TIMESIZE 64
#else
-# define __MSQ_PAD_AFTER_TIME 1
+/* For others, time size is word size. */
+# define __TIMESIZE __WORDSIZE
#endif
-#define __MSQ_PAD_BEFORE_TIME 0