Bug#145857: marked as done (libc6-dev: three problems in <time.h>)
Your message dated Thu, 20 Mar 2003 00:39:34 +0900
with message-id <80znnrl615.wl@oris.opensource.jp>
and subject line Bug#145857: libc6-dev: three problems in <time.h>
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 5 May 2002 06:34:10 +0000
>From jeff@jab.org Sun May 05 01:34:10 2002
Return-path: <jeff@jab.org>
Received: from adsl-209-233-24-252.dsl.snfc21.pacbell.net (yodel.jab.org) [209.233.24.252] (mail)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 174Faz-0002zB-00; Sun, 05 May 2002 01:34:10 -0500
Received: from jeff by yodel.jab.org with local (Exim 3.35 #1 (Debian))
id 174FdD-00041k-00; Sat, 04 May 2002 23:36:27 -0700
From: Jeff Breidenbach <jeff@jab.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libc6-dev: three problems in <time.h>
X-Mailer: reportbug 1.50
Date: Sat, 04 May 2002 23:36:27 -0700
Message-Id: <E174FdD-00041k-00@yodel.jab.org>
Delivered-To: submit@bugs.debian.org
Package: libc6-dev
Version: 2.2.5-4
Severity: normal
Tags: patch
This is an upstream bug, not a Debian bug.
I decided to track down a compiler warning. It turned out to be a
buggy libc6 header file, and was NOT harmless. Here's a testcase to
demonstrate the compiler warning. If I switch the order of the
includes, everything is fine.
#include <time.h>
#include <sched.h>
main () {
return 0;
}
gcc -o testcase -ansi -Werror testcase.c
cc1: warnings being treated as errors
In file included from testcase.c:2:
/usr/include/sched.h:63: warning: `struct timespec' declared inside parameter l\ist
/usr/include/sched.h:63: warning: its scope is only this definition or declarat\ion, which is probably not what you want.
make: *** [all] Error 1
Basically, glibc is designed so that <time.h> will cough up specific
definitions when directed to do so by other libc header files. In this
case, <sched.h> is asking for timespec using a directive called
__need_timespec. Unfortunately, <time.h> contains a complicated rats
nest of #ifdefs, to the point where things were hard to understand and
buggy. In this case, the guard against multiple inclusion is blocked
the directive from being activated. I also noticed the following
couple of bugs:
diff -u orig-time.h time.h
--- orig-time.h Sat May 4 23:19:08 2002
+++ time.h Sat May 4 23:22:59 2002
@@ -22,8 +22,8 @@
#ifndef _TIME_H
-#if (! defined __need_time_t && !defined __need_clock_t && \
- ! defined __need_timespec)
+#if (! defined __need_timer_t && !defined __need_clock_t && \
+ ! defined __need_timespec && !defined __need_clockid_t)
# define _TIME_H 1
# include <features.h>
@@ -82,7 +82,7 @@
typedef __clockid_t clockid_t;
#endif /* clockid_t not defined and <time.h> or need clockid_t. */
-#undef __clockid_time_t
+#undef __need_clockid_t
#if !defined __timer_t_defined && \
((defined _TIME_H && defined __USE_POSIX199309) || defined __need_timer_t)
In summary, I think the root cause of the problem is <time.h> is too
confusing due to #ifdefs trying to do too many things at once. So I
made what I feel is a more maintainable version and will attach in the
next email to this bug report, which should treat the disease as well
as the symptoms. Of course, for such an important file, there should be
a code review before either including with debian or upstream glibc.
Thank goodness gcc -ansi can catch this stuff.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux yodel 2.4.18-bf2.4 #1 Sam Mär 23 18:45:17 CET 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libc6-dev depends on:
ii libc6 2.2.5-4 GNU C Library: Shared libraries an
---------------------------------------
Received: (at 145857-done) by bugs.debian.org; 19 Mar 2003 15:39:36 +0000
>From gotom@debian.or.jp Wed Mar 19 09:39:36 2003
Return-path: <gotom@debian.or.jp>
Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] (postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18vffE-0007xJ-00; Wed, 19 Mar 2003 09:39:36 -0600
Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73])
by oris.opensource.gr.jp (Postfix) with ESMTP
id 9DD9DC33C7; Thu, 20 Mar 2003 00:39:34 +0900 (JST)
Date: Thu, 20 Mar 2003 00:39:34 +0900
Message-ID: <80znnrl615.wl@oris.opensource.jp>
From: GOTO Masanori <gotom@debian.or.jp>
To: Jeff Breidenbach <jeff@jab.org>, 145857-done@bugs.debian.org
Cc: gotom@debian.or.jp
Subject: Re: Bug#145857: libc6-dev: three problems in <time.h>
In-Reply-To: <[🔎] 80n0k06g9w.wl@oris.opensource.jp>
References: <[🔎] E18srWK-0005WR-00@yodel.jab.org>
<[🔎] 80n0k06g9w.wl@oris.opensource.jp>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: 145857-done@bugs.debian.org
X-Spam-Status: No, hits=-1.8 required=4.0
tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,
USER_AGENT
version=2.44
X-Spam-Level:
At Wed, 12 Mar 2003 19:16:59 +0900,
GOTO Masanori wrote:
>
> At Tue, 11 Mar 2003 13:42:48 -0800,
> Jeff Breidenbach wrote:
> > The sample code now works in 2.3.1-14. Great!
> >
> > > #include <time.h>
> > > #include <sched.h>
> > >
> > > main () {
> > > return 0;
> > > }
> > >
> > > gcc -o testcase -ansi -Werror testcase.c
> >
> > There still appears to be at least one bug in <time.h>.
> > If I have __need_clockid_t defined, why does <time.h>
> > define _TIME_H ?
> >
> > In other words, why is __need_clockid_t treated differently
> > from __need_time_t, __need_clock_t and __need_timespec ?
>
> I think checking __need_clockid_t (and __need_timer_t, so on)
> is less meaning compared with __need_clock_t, __need_timespec.
OK, now I close this bug.
Regards,
-- gotom
Reply to: