[Bug libc/16437] New: struct timespec definition is non-conforming on x32 and perhaps other archs

[Bug libc/16437] New: struct timespec definition is non-conforming on x32 and perhaps other archs

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

            Bug ID: 16437
           Summary: struct timespec definition is non-conforming on x32
                    and perhaps other archs
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
                CC: drepper.fsp at gmail dot com

glibc's definition of struct timespec is wrong: it's using __syscall_slong_t
rather than long. This violates the requirements of both POSIX and C11. See C11
7.27.1 Components of time, paragraph 4:

"The range and precision of times representable in clock_t and time_t are
implementation-defined. The timespec structure shall contain at least the
following members, in any order.

         time_t tv_sec; // whole seconds -- >= 0
         long   tv_nsec; // nanoseconds -- [0, 999999999]"

This breaks conforming code such as:

struct timespec ts;
sscanf("42", "%ld", &ts.tv_nsec);

on targets where __syscall_slong_t is not simply long. For example, on x32,
after the above sscanf call, the upper bits of ts.tv_nsec will still contain
junk. This is just one example of the breakage; there are many others.

Unfortunately fixing this is difficult because the kernel is broken too; simply
correcting the type will result in userspace failing to zero the upper bits,
which the kernel will then wrongly read as part of a 64-bit value.
kernel/compat.c should be zeroing the upper bits of tv_nsec when reading
timespec from userspace. Unless it does so, workaround code is required in
userspace to copy timespec to a temp buffer before passing it to the kernel and
to sign-extend the temporary copy into the padding bits which the kernel will
wrongly interpret as value bits.

I'm not sure if other archs (maybe MIPS n32?) are also affected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16437] struct timespec definition is non-conforming on x32 and perhaps other archs

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=16437

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Only x32 has a funny definition of __SYSCALL_SLONG_TYPE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16437] struct timespec definition is non-conforming on x32 and perhaps other archs

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
You mean as opposed to the problem also existing on MIPS n32 or other targets?
That's good to hear, but the problem is still there on x32.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |x86_64-*-*
            Summary|struct timespec definition  |[x86_64] struct timespec
                   |is non-conforming on x32    |definition is
                   |and perhaps other archs     |non-conforming on x32 and
                   |                            |perhaps other archs

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |hjl.tools at gmail dot com
         Resolution|---                         |WONTFIX

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Rich Felker from comment #0)
> glibc's definition of struct timespec is wrong: it's using __syscall_slong_t
> rather than long. This violates the requirements of both POSIX and C11. See
> C11 7.27.1 Components of time, paragraph 4:
> 
> "The range and precision of times representable in clock_t and time_t are
> implementation-defined. The timespec structure shall contain at least the
> following members, in any order.
> 
>          time_t tv_sec; // whole seconds -- >= 0
>          long   tv_nsec; // nanoseconds -- [0, 999999999]"
> 
> This breaks conforming code such as:
> 
> struct timespec ts;
> sscanf("42", "%ld", &ts.tv_nsec);
> 

Both clang and GCC will complain:

[hjl@gnu-6 tmp]$ cat t.c
#include <stdio.h>
#include <sys/time.h>

long
foo (const char *str)
{
  struct timespec ts;
  sscanf(str, "%ld", &ts.tv_nsec);
  return ts.tv_nsec;
}
[hjl@gnu-6 tmp]$ /opt/llvm/x32/bin/clang -c -mx32 t.c
t.c:8:22: warning: format specifies type 'long *' but the argument has type
      '__syscall_slong_t *' (aka 'long long *') [-Wformat]
  sscanf(str, "%ld", &ts.tv_nsec);
               ~~~   ^~~~~~~~~~~
               %lld
1 warning generated.
[hjl@gnu-6 tmp]$ gcc -Wall -c  -mx32 t.c
t.c: In function ‘foo’:
t.c:8:3: warning: format ‘%ld’ expects argument of type ‘long int *’, but
argument 3 has type ‘__syscall_slong_t *’ [-Wformat=]
   sscanf(str, "%ld", &ts.tv_nsec);
   ^
[hjl@gnu-6 tmp]$ 

This issue has been discussed in March, 2012:

https://sourceware.org/ml/libc-alpha/2012-03/msg00438.html

I won't change x32.  I consider this issue is closed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-27408-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Feb 11 21:28:14 2015
Return-Path: <glibc-bugs-return-27408-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 12364 invoked by alias); 11 Feb 2015 21:28:14 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 12266 invoked by uid 48); 11 Feb 2015 21:28:10 -0000
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs
Date: Wed, 11 Feb 2015 21:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jsm28 at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-16437-131-QMSgupsKRN@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16437-131@http.sourceware.org/bugzilla/>
References: <bug-16437-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00143.txt.bz2
Content-length: 740

https://sourceware.org/bugzilla/show_bug.cgi?id\x16437

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #4 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
There is no consensus to close this bug; indeed, I think there is consensus
that this should be fixed (in glibc if not in the kernel).  Furthermore, there
was no interest in the Austin Group in legitimizing this bug when it was raised
in May 2014.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |time

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
             Status|REOPENED                    |RESOLVED

--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixing it would be an ABI break, which would require possible a new minor
version for x32. I suggested a fix [1], however other developers raised that is
not the best option.

[1] https://sourceware.org/pipermail/libc-alpha/2021-December/133919.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
Reopening again because I disagree that this is an ABI break, at least in the
sense of the ABI at the application-libc boundary. Before and after the change,
the layout (location of the meaningful part of tv_nsec) is in the same place,
and as long as functions which produce timespec as output store zeros in the
padding bits, applications which access tv_nsec as a 64-bit member will read
the correct value.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/16437] [x86_64] struct timespec definition is non-conforming on x32 and perhaps other archs

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.