From owner-freebsd-standards Sun May 26 0:42:38 2002 Delivered-To: freebsd-standards@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 50E3037B407; Sun, 26 May 2002 00:42:36 -0700 (PDT) Received: (from tjr@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g4Q7gZH67128; Sun, 26 May 2002 00:42:35 -0700 (PDT) (envelope-from tjr) Date: Sun, 26 May 2002 00:42:35 -0700 (PDT) From: Message-Id: <200205260742.g4Q7gZH67128@freefall.freebsd.org> To: tim@robbins.dropbear.id.au, tjr@FreeBSD.org, tjr@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/36076: Implementation of POSIX fuser command Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Synopsis: Implementation of POSIX fuser command State-Changed-From-To: open->suspended State-Changed-By: tjr State-Changed-When: Sun May 26 00:36:35 PDT 2002 State-Changed-Why: This should probably be implemented in C, as part of fstat(1) instead of a shell script wrapper around it, which has proven to be too hard to make robust. I don't have the time right now to overhaul fstat so that it supports the traditional fstat output and the fuser output. Responsible-Changed-From-To: tjr->freebsd-standards Responsible-Changed-By: tjr Responsible-Changed-When: Sun May 26 00:36:35 PDT 2002 Responsible-Changed-Why: This should probably be implemented in C, as part of fstat(1) instead of a shell script wrapper around it, which has proven to be too hard to make robust. I don't have the time right now to overhaul fstat so that it supports the traditional fstat output and the fuser output. http://www.freebsd.org/cgi/query-pr.cgi?pr=36076 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun May 26 21:44: 7 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mail.cscoms.com (mail.cscoms.com [202.183.255.23]) by hub.freebsd.org (Postfix) with ESMTP id 7E1B237B404 for ; Sun, 26 May 2002 21:44:01 -0700 (PDT) Received: from mail.cscoms.com (dial-220.ras-16.bkk.c.cscoms.com [203.170.151.158]) by mail.cscoms.com (8.11.1/8.11.1) with SMTP id g4R4hxJ28984 for ; Mon, 27 May 2002 11:43:59 +0700 (GMT) Message-Id: <1022474905.520@cscoms.com> Date: Mon, 27 May 2002 11:48:25 0700 To: standards@FreeBSD.org From: "richy" Subject: งาน Part Time สร้างรายได้ดี ใช้เทคโนโลยีทำงานแทนคุณ MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG งาน Part Time ใช้เทคโนโลยีทำงานแทนคุณ ไม่กระทบต่อชีวิตประจำวันของคุณ ไม่ว่าคุณจะเป็นใคร คุณต้องการงานอย่างนี้หรือเปล่า ?? - โอกาสที่จะเป็นเจ้าของกิจการแบบง่าย ๆ - มีธุรกิจของตนเองบน Internet ( E-Commerce ) - เปิดดำเนินงานตลอด 24 ชั่วโมงต่อวัน 7วันต่อสัปดาห์ 365วันในหนึ่งปีไม่มีวันหยุด - เงินลงทุนต่ำ รายได้สูง Part Time 15,000 บาทขึ้นไปต่อเดือน / Full Time 45,000 บาทขึ้นไป - ไม่ต้องจ้างพนักงานขาย ไม่ต้องปวดหัวเรื่องขึ้นค่าแรง การนัดหยุดงาน และไม่ต้องจ่ายสวัสดิการ - ใช้เทคโนโลยีทำงานแทนคุณ ไม่กระทบต่อการดำเนินชีวิตประจำวันของคุณ เพียงแค่วันละ 2-3 ชั่วโมง - ทำงานจากที่ไหนก็ได้ แต่สามารถมีธุรกิจได้ทั่วโลก - ไม่ต้องกักตุนสินค้า ไม่เสี่ยงต่อทุนจม - มีระบบจัดส่งสินค้า ทั้งในและต่างประเทศ - ไม่ใช่การ Knock Door ขายสินค้า แต่ลูกค้าจะวิ่งเข้ามาหาคุณ ฯลฯ ถ้าคุณอยากมีกิจการของตัวเองและยังสามารถใช้เวลาส่วนใหญ่กับสิ่งที่คุณชอบ คุณทำได้แน่นอน พบเราได้ที่นี่ http://www.thaiworkathome.com/win โทร 0-2277-7850 ต่อ 57 ==คุณอาจในได้พบในสิ่งที่คุณหามานานในชีวิตการทำงาน== ขออภัยหากคุณไม่ต้องการแต่ได้รับ mail นี้ หากไม่ต้องการรับข่าวสารจากเราอีก กรุณา CLICK ไปที่ http://www.thaiworkathome.com/unsubscribe.asp กรอก email-address ของท่าน และ submit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon May 27 20:25:13 2002 Delivered-To: freebsd-standards@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 9FA2737B407 for ; Mon, 27 May 2002 20:25:08 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g4S3NWd93961 for standards@FreeBSD.org; Mon, 27 May 2002 23:23:32 -0400 (EDT) (envelope-from mike) Date: Mon, 27 May 2002 23:23:32 -0400 From: Mike Barcroft To: standards@FreeBSD.org Subject: wait.diff for review Message-ID: <20020527232332.A93657@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline Organization: The FreeBSD Project Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline While looking though , I noticed waitpid() was missing the new WCONTINUED option. Attached is a patch which implements it. I'd appreciate reviews as I'm not much of a kernel hacker. Best regards, Mike Barcroft --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wait.diff" Add POSIX.1-2001 WCONTINUED option for waitpid(2). A proc flag (P_CONTINUED) is set when a stopped process receives a SIGCONT and cleared after it has notified a parent process that has requested notification via waitpid(2) with WCONTINUED specified in its options operand. The status value can be checked with the new WIFCONTINUED() macro. Index: kern/kern_exit.c =================================================================== RCS file: /work/repo/src/sys/kern/kern_exit.c,v retrieving revision 1.164 diff -u -r1.164 kern_exit.c --- kern/kern_exit.c 6 May 2002 19:31:28 -0000 1.164 +++ kern/kern_exit.c 28 May 2002 02:57:01 -0000 @@ -505,7 +505,7 @@ uap->pid = -q->p_pgid; PROC_UNLOCK(q); } - if (uap->options &~ (WUNTRACED|WNOHANG|WLINUXCLONE)) + if (uap->options &~ (WUNTRACED|WNOHANG|WCONTINUED|WLINUXCLONE)) return (EINVAL); mtx_lock(&Giant); loop: @@ -685,6 +685,22 @@ PROC_UNLOCK(p); error = 0; } + mtx_unlock(&Giant); + return (error); + } + if (uap->options & WCONTINUED && (p->p_flag & P_CONTINUED)) { + sx_xunlock(&proctree_lock); + td->td_retval[0] = p->p_pid; + p->p_flag &= ~P_CONTINUED; + PROC_UNLOCK(p); + + if (uap->status) { + status = SIGCONT; + error = copyout((caddr_t)&status, + (caddr_t)uap->status, sizeof(status)); + } else + error = 0; + mtx_unlock(&Giant); return (error); } Index: kern/kern_sig.c =================================================================== RCS file: /work/repo/src/sys/kern/kern_sig.c,v retrieving revision 1.165 diff -u -r1.165 kern_sig.c --- kern/kern_sig.c 19 May 2002 00:14:49 -0000 1.165 +++ kern/kern_sig.c 28 May 2002 02:36:25 -0000 @@ -1436,6 +1436,8 @@ } } } else { + p->p_flag |= P_CONTINUED; + wakeup((caddr_t)p->p_pptr); if (td->td_wchan == NULL) goto run; p->p_stat = SSLEEP; Index: sys/proc.h =================================================================== RCS file: /work/repo/src/sys/sys/proc.h,v retrieving revision 1.221 diff -u -r1.221 proc.h --- sys/proc.h 19 May 2002 00:14:50 -0000 1.221 +++ sys/proc.h 28 May 2002 02:58:03 -0000 @@ -486,6 +486,7 @@ #define P_WEXIT 0x02000 /* Working on exiting. */ #define P_EXEC 0x04000 /* Process called exec. */ #define P_KSES 0x08000 /* Process is using KSEs. */ +#define P_CONTINUED 0x10000 /* Proc has continued from a stopped state. */ /* Should be moved to machine-dependent areas. */ #define P_UNUSED100000 0x100000 Index: sys/wait.h =================================================================== RCS file: /work/repo/src/sys/sys/wait.h,v retrieving revision 1.13 diff -u -r1.13 wait.h --- sys/wait.h 27 May 2002 00:55:17 -0000 1.13 +++ sys/wait.h 28 May 2002 02:58:46 -0000 @@ -61,6 +61,7 @@ #define WTERMSIG(x) (_WSTATUS(x)) #define WIFEXITED(x) (_WSTATUS(x) == 0) #define WEXITSTATUS(x) (_W_INT(x) >> 8) +#define WIFCONTINUED(x) (x == 0x13) /* 0x13 == SIGCONT */ #ifndef _POSIX_SOURCE #define WCOREDUMP(x) (_W_INT(x) & WCOREFLAG) @@ -79,6 +80,7 @@ */ #define WNOHANG 1 /* don't hang in wait */ #define WUNTRACED 2 /* tell about stopped, untraced children */ +#define WCONTINUED 4 /* Report a job control continued process. */ #define WLINUXCLONE 0x80000000 /* wait for kthread spawned from linux_clone */ #ifndef _POSIX_SOURCE --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 11:20:31 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by hub.freebsd.org (Postfix) with ESMTP id 211A937B40A for ; Tue, 28 May 2002 11:16:52 -0700 (PDT) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17ClWc-0003rl-00 (Debian); Tue, 28 May 2002 19:16:50 +0100 Date: Tue, 28 May 2002 19:16:50 +0100 From: Tony Finch To: freebsd-standards@freebsd.org Subject: clock(3) standardization Message-ID: <20020528191650.A8322@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I noticed that clock(3) currently violates a requirement of POSIX 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs are inconsistent and somtimes different from what is in clocks(7). However clock() isn't mentioned on the C99 project page. This patch changes clock_t to a size that is consistent on all platforms and big enough to allow CLOCKS_PER_SEC to be increased to 1e6 without loss of range. This implies a binary compatibility breakage for programs that call clock() or times(), and therefore a __FreeBSD_version bump which I haven't included in this patch. I also haven't tested it yet :-) Is there anything else to worry about that I might not be aware of? This patch is rather repetitive. IWBNI the MI stuff in machine/ansi.h could be moved into an MI header, e.g. sys/ansi.h which might be included by machine/ansi.h or vice versa. Tony. -- f.a.n.finch http://dotat.at/ SOLE LUNDY FASTNET: SOUTHWESTERLY 6 TO GALE 8 DECREASING 5 OR 6. SQUALLY SHOWERS. GOOD. --- lib/libc/gen/clock.3 20 Nov 2001 13:43:58 -0000 1.11 +++ lib/libc/gen/clock.3 28 May 2002 17:13:51 -0000 @@ -56,6 +56,9 @@ calling process, measured in .Dv CLOCKS_PER_SEC Ns s of a second. +.Dv CLOCKS_PER_SEC +is defined to be one million in +.In time.h . .Sh RETURN VALUES The .Fn clock @@ -68,13 +71,6 @@ The .Fn clock function conforms to -.St -isoC . -However, -.St -susv2 -requires -.Dv CLOCKS_PER_SEC -to be defined as one million. -.Fx -does not conform to this requirement; -changing the value would introduce binary incompatibility -and one million is still inadequate on modern processors. +.St -isoC +and +.St -p1003.1-2001 . --- share/man/man7/clocks.7 17 Mar 2002 15:02:20 -0000 1.19 +++ share/man/man7/clocks.7 28 May 2002 17:54:50 -0000 @@ -54,7 +54,7 @@ .It The clock reported by .Xr clock 3 . -This is a virtual clock with a frequency that happens to be 128. +This is a virtual clock with a frequency that happens to be 1000000. Its actual frequency is given by the macro .Dv CLOCKS_PER_SEC . Note that @@ -70,11 +70,11 @@ conformance. It is implemented by calling .Xr getrusage 2 -and throwing away information and resolution. +and throwing away information. .It The clock reported by .Xr times 3 . -This is a virtual clock with a frequency that happens to be 128. +This is a virtual clock with a frequency that happens to be 1000000. Its actual frequency is given by the macro .Dv CLK_TCK (deprecated; do not use) and by @@ -97,7 +97,7 @@ .Xr gettimeofday 2 and .Xr getrusage 2 -and throwing away information and resolution. +and throwing away information. .It The profiling clock. This is a real clock with frequency 1024. --- sys/alpha/include/ansi.h 10 May 2002 02:21:05 -0000 1.29 +++ sys/alpha/include/ansi.h 28 May 2002 17:46:08 -0000 @@ -47,7 +47,7 @@ * #undef _BSD_SIZE_T_ * #endif */ -#define _BSD_CLOCK_T_ int /* clock() */ +#define _BSD_CLOCK_T_ __int64_t /* clock(), times() */ #define _BSD_CLOCKID_T_ int /* clock_gettime()... */ #define _BSD_FFLAGS_T_ __uint_least32_t /* file flags */ #define _BSD_MBSTATE_T_ __mbstate_t /* mbstate_t */ @@ -106,17 +106,11 @@ */ /* - * Frequencies of the clock ticks reported by clock() and times(). They - * are the same as stathz for bogus historical reasons. They should be - * 1e6 because clock() and times() are implemented using getrusage() and - * there is no good reason why they should be less accurate. There is - * the bad reason that (broken) programs might not like clock_t or - * CLOCKS_PER_SEC being ``double'' (``unsigned long'' is not large enough - * to hold the required 24 hours worth of ticks if the frequency is - * 1000000ul, and ``unsigned long long'' would be nonstandard). + * Frequencies of the clock ticks reported by clock() and times(). + * POSIX 2001 requires CLOCKS_PER_SEC to be 1e6. */ -#define _BSD_CLK_TCK_ 100 -#define _BSD_CLOCKS_PER_SEC_ 100 +#define _BSD_CLK_TCK_ 1000000 +#define _BSD_CLOCKS_PER_SEC_ 1000000 /* * We define this here since both and needs it. --- sys/arm/include/ansi.h 10 May 2002 02:20:33 -0000 1.17 +++ sys/arm/include/ansi.h 28 May 2002 17:46:17 -0000 @@ -46,7 +46,7 @@ * #undef _BSD_SIZE_T_ * #endif */ -#define _BSD_CLOCK_T_ unsigned long /* clock()... */ +#define _BSD_CLOCK_T_ __int64_t /* clock(), times() */ #define _BSD_CLOCKID_T_ int /* clock_gettime()... */ #define _BSD_MBSTATE_T_ __mbstate_t /* mbstate_t */ #define _BSD_PTRDIFF_T_ int /* ptr1 - ptr2 */ @@ -98,17 +98,11 @@ */ /* - * Frequencies of the clock ticks reported by clock() and times(). They - * are the same as stathz for bogus historical reasons. They should be - * 1e6 because clock() and times() are implemented using getrusage() and - * there is no good reason why they should be less accurate. There is - * the bad reason that (broken) programs might not like clock_t or - * CLOCKS_PER_SEC being ``double'' (``unsigned long'' is not large enough - * to hold the required 24 hours worth of ticks if the frequency is - * 1000000ul, and ``unsigned long long'' would be nonstandard). + * Frequencies of the clock ticks reported by clock() and times(). + * POSIX 2001 requires CLOCKS_PER_SEC to be 1e6. */ -#define _BSD_CLK_TCK_ 100 -#define _BSD_CLOCKS_PER_SEC_ 100 +#define _BSD_CLK_TCK_ 1000000 +#define _BSD_CLOCKS_PER_SEC_ 1000000 /* * We define this here since both and needs it. --- sys/i386/include/ansi.h 10 May 2002 02:00:00 -0000 1.38 +++ sys/i386/include/ansi.h 28 May 2002 17:46:29 -0000 @@ -46,7 +46,7 @@ * #undef _BSD_SIZE_T_ * #endif */ -#define _BSD_CLOCK_T_ unsigned long /* clock()... */ +#define _BSD_CLOCK_T_ __int64_t /* clock(), times() */ #define _BSD_CLOCKID_T_ int /* clock_gettime()... */ #define _BSD_FFLAGS_T_ __uint_least32_t /* file flags */ #define _BSD_MBSTATE_T_ __mbstate_t /* mbstate_t */ @@ -100,17 +100,11 @@ */ /* - * Frequencies of the clock ticks reported by clock() and times(). They - * are the same as stathz for bogus historical reasons. They should be - * 1e6 because clock() and times() are implemented using getrusage() and - * there is no good reason why they should be less accurate. There is - * the bad reason that (broken) programs might not like clock_t or - * CLOCKS_PER_SEC being ``double'' (``unsigned long'' is not large enough - * to hold the required 24 hours worth of ticks if the frequency is - * 1000000ul, and ``unsigned long long'' would be nonstandard). + * Frequencies of the clock ticks reported by clock() and times(). + * POSIX 2001 requires CLOCKS_PER_SEC to be 1e6. */ -#define _BSD_CLK_TCK_ 128 -#define _BSD_CLOCKS_PER_SEC_ 128 +#define _BSD_CLK_TCK_ 1000000 +#define _BSD_CLOCKS_PER_SEC_ 1000000 /* * We define this here since both and needs it. --- sys/ia64/include/ansi.h 2 May 2002 09:04:29 -0000 1.21 +++ sys/ia64/include/ansi.h 28 May 2002 17:47:28 -0000 @@ -47,7 +47,7 @@ * #undef _BSD_SIZE_T_ * #endif */ -#define _BSD_CLOCK_T_ int /* clock() */ +#define _BSD_CLOCK_T_ __int64_t /* clock(), times() */ #define _BSD_CLOCKID_T_ int /* clockid_t */ #define _BSD_FFLAGS_T_ __uint_least32_t /* file flags */ #define _BSD_MBSTATE_T_ __mbstate_t /* mbstate_t */ @@ -101,17 +101,11 @@ */ /* - * Frequencies of the clock ticks reported by clock() and times(). They - * are the same as stathz for bogus historical reasons. They should be - * 1e6 because clock() and times() are implemented using getrusage() and - * there is no good reason why they should be less accurate. There is - * the bad reason that (broken) programs might not like clock_t or - * CLOCKS_PER_SEC being ``double'' (``unsigned long'' is not large enough - * to hold the required 24 hours worth of ticks if the frequency is - * 1000000ul, and ``unsigned long long'' would be nonstandard). + * Frequencies of the clock ticks reported by clock() and times(). + * POSIX 2001 requires CLOCKS_PER_SEC to be 1e6. */ -#define _BSD_CLK_TCK_ 100 -#define _BSD_CLOCKS_PER_SEC_ 100 +#define _BSD_CLK_TCK_ 1000000 +#define _BSD_CLOCKS_PER_SEC_ 1000000 /* * We define this here since both and needs it. --- sys/powerpc/include/ansi.h 10 May 2002 02:12:04 -0000 1.21 +++ sys/powerpc/include/ansi.h 28 May 2002 17:48:36 -0000 @@ -46,7 +46,7 @@ * #undef _BSD_SIZE_T_ * #endif */ -#define _BSD_CLOCK_T_ int /* clock() */ +#define _BSD_CLOCK_T_ __int64_t /* clock(), times() */ #define _BSD_FFLAGS_T_ __uint_least32_t /* file flags */ #define _BSD_CLOCKID_T_ int /* clockid_t */ #define _BSD_MBSTATE_T_ __mbstate_t /* mbstate_t */ @@ -107,17 +107,11 @@ */ /* - * Frequencies of the clock ticks reported by clock() and times(). They - * are the same as stathz for bogus historical reasons. They should be - * 1e6 because clock() and times() are implemented using getrusage() and - * there is no good reason why they should be less accurate. There is - * the bad reason that (broken) programs might not like clock_t or - * CLOCKS_PER_SEC being ``double'' (``unsigned long'' is not large enough - * to hold the required 24 hours worth of ticks if the frequency is - * 1000000ul, and ``unsigned long long'' would be nonstandard). + * Frequencies of the clock ticks reported by clock() and times(). + * POSIX 2001 requires CLOCKS_PER_SEC to be 1e6. */ -#define _BSD_CLK_TCK_ 100 -#define _BSD_CLOCKS_PER_SEC_ 100 +#define _BSD_CLK_TCK_ 1000000 +#define _BSD_CLOCKS_PER_SEC_ 1000000 /* * We define this here since both and needs it. --- sys/sparc64/include/ansi.h 10 May 2002 02:02:54 -0000 1.15 +++ sys/sparc64/include/ansi.h 28 May 2002 17:49:36 -0000 @@ -47,7 +47,7 @@ * #undef _BSD_SIZE_T_ * #endif */ -#define _BSD_CLOCK_T_ int /* clock() */ +#define _BSD_CLOCK_T_ __int64_t /* clock(), times() */ #define _BSD_CLOCKID_T_ int /* clock_gettime()... */ #define _BSD_FFLAGS_T_ __uint_least32_t /* file flags */ #define _BSD_MBSTATE_T_ __mbstate_t /* mbstate_t */ @@ -101,17 +101,11 @@ */ /* - * Frequencies of the clock ticks reported by clock() and times(). They - * are the same as stathz for bogus historical reasons. They should be - * 1e6 because clock() and times() are implemented using getrusage() and - * there is no good reason why they should be less accurate. There is - * the bad reason that (broken) programs might not like clock_t or - * CLOCKS_PER_SEC being ``double'' (``unsigned long'' is not large enough - * to hold the required 24 hours worth of ticks if the frequency is - * 1000000ul, and ``unsigned long long'' would be nonstandard). + * Frequencies of the clock ticks reported by clock() and times(). + * POSIX 2001 requires CLOCKS_PER_SEC to be 1e6. */ -#define _BSD_CLK_TCK_ 100 -#define _BSD_CLOCKS_PER_SEC_ 100 +#define _BSD_CLK_TCK_ 1000000 +#define _BSD_CLOCKS_PER_SEC_ 1000000 /* * We define this here since both and needs it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 12:53:39 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 40E0537B417 for ; Tue, 28 May 2002 12:53:08 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA13792; Wed, 29 May 2002 05:52:59 +1000 Date: Wed, 29 May 2002 05:56:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Tony Finch Cc: freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization In-Reply-To: <20020528191650.A8322@chiark.greenend.org.uk> Message-ID: <20020529051638.F22456-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 28 May 2002, Tony Finch wrote: > I noticed that clock(3) currently violates a requirement of POSIX > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > are inconsistent and somtimes different from what is in clocks(7). That is only in a (broken) XSI extension. "Fixing" this would mainly break binary compatibility since it would change from one historical wrong value to another (128 -> 1000000). The first C standard got this right by permitting it to be a runtime parameter. This value should be which may be a few billion on current machines. This requires clock_t to be much larger than uint32_t so that it can represent 24 hours in ticks. clock_t should probably be double. POSIX's clock_getres() is broken as designed too. It specifies returning the precision in a timeval, by FreeBSD's potential resolution of (1 ) started overflowing a year or two ago when TSC frequencies started exceeding 1 billion). > This patch changes clock_t to a size that is consistent on all platforms > and big enough to allow CLOCKS_PER_SEC to be increased to 1e6 without > loss of range. This implies a binary compatibility breakage for programs > that call clock() or times(), and therefore a __FreeBSD_version bump > which I haven't included in this patch. I also haven't tested it yet :-) I would prefer to break things only once in the transition to the correct non-XSI-supporting implementation, something like this: - clock_t of type double, long double or uint64_t or larger - CLOCKS_PER_SECOND = ((clock_t)sysconf(_SC_CLK_TCK)) (this limits it to LONG_MAX, but longs will soon always be >= 64 bits) - sysconf(_SC_CLK_TCK) returns (scaled down a little if necessary) I actually prefer to let this rot and tell everyone to use clock_gettime(). > This patch is rather repetitive. IWBNI the MI stuff in machine/ansi.h > could be moved into an MI header, e.g. sys/ansi.h which might be included > by machine/ansi.h or vice versa. This is potentially very MD. E.g., uint64_t is a good type for clock_t on 64-bit machines, but double is probably more efficient on 32-bit ones. Machines with a clock frequency of 18.4 Hz need a double to even represent the frequency. _BSD_CLOCKS_PER_SECOND_ was gratuitously MD because most copies of it were cloned from a rotted value for CLK_TCK in NetBSD starting with the alpha, despite the alpha not having any binary compatibility baggage so it could have started with a reasonably large value like 1e6 :-). Clocks.7 mentions too many clocks but doesn't manage to mention any except old i386 ones. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 13:19:53 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by hub.freebsd.org (Postfix) with ESMTP id B67A037B403 for ; Tue, 28 May 2002 13:19:50 -0700 (PDT) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17CnRb-0007ct-00 (Debian); Tue, 28 May 2002 21:19:47 +0100 Date: Tue, 28 May 2002 21:19:47 +0100 From: Tony Finch To: Bruce Evans Cc: Tony Finch , freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization Message-ID: <20020528211947.A20393@chiark.greenend.org.uk> References: <20020528191650.A8322@chiark.greenend.org.uk> <20020529051638.F22456-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529051638.F22456-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, May 29, 2002 at 05:56:17AM +1000 Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 29, 2002 at 05:56:17AM +1000, Bruce Evans wrote: > On Tue, 28 May 2002, Tony Finch wrote: > > > I noticed that clock(3) currently violates a requirement of POSIX > > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > > are inconsistent and somtimes different from what is in clocks(7). > > That is only in a (broken) XSI extension. "Fixing" this would mainly > break binary compatibility since it would change from one historical > wrong value to another (128 -> 1000000). The first C standard got this > right by permitting it to be a runtime parameter. This value should > be which may be a few billion on > current machines. This requires clock_t to be much larger than uint32_t > so that it can represent 24 hours in ticks. clock_t should probably be > double. But to do this would require changing the implementation to use something other than getrusage() to implement clock() and times(). Wouldn't it be better to add a non-standard interface for getting the higher resolution value, instead of being non-compliant? There's currently a discussion on comp.std.c about relaxing the C99 definition of CLOCKS_PER_SEC back to the C89 definition. > I actually prefer to let this rot and tell everyone to use clock_gettime(). We currently tell everyone to use getrusage(). Tony. -- f.a.n.finch http://dotat.at/ SOUTH BISCAY: NORTHWESTERLY BECOMING VARIABLE 3 OR 4. MAINLY FAIR. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 14: 7:44 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 30E3237B43F for ; Tue, 28 May 2002 14:07:21 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA18158; Wed, 29 May 2002 07:07:14 +1000 Date: Wed, 29 May 2002 07:10:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Tony Finch Cc: freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization In-Reply-To: <20020528211947.A20393@chiark.greenend.org.uk> Message-ID: <20020529064206.B22731-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 28 May 2002, Tony Finch wrote: > On Wed, May 29, 2002 at 05:56:17AM +1000, Bruce Evans wrote: > > On Tue, 28 May 2002, Tony Finch wrote: > > > > > I noticed that clock(3) currently violates a requirement of POSIX > > > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > > > are inconsistent and somtimes different from what is in clocks(7). > > > > That is only in a (broken) XSI extension. "Fixing" this would mainly > > break binary compatibility since it would change from one historical > > wrong value to another (128 -> 1000000). The first C standard got this > > right by permitting it to be a runtime parameter. This value should > > be which may be a few billion on > > current machines. This requires clock_t to be much larger than uint32_t > > so that it can represent 24 hours in ticks. clock_t should probably be > > double. > > But to do this would require changing the implementation to use something > other than getrusage() to implement clock() and times(). Wouldn't it be > better to add a non-standard interface for getting the higher resolution > value, instead of being non-compliant? clock() and times() can keep using getrusage() for a while. The important points are to enlarge clock_t and make CLOCKS_PER_SECOND a non-constant so that it can be changed without breaking binary compatibility. BTW, the Linux emulator has several Linux constants for CLK_TCK compiled in. times(3) is is times(2) in Linux, so if Linux changed it then the emulator would need to have even more Linux constants and ifdefs to decide which one to use... > There's currently a discussion on comp.std.c about relaxing the C99 > definition of CLOCKS_PER_SEC back to the C89 definition. I didn't know that C99 changed it. I read com.std.c every week or so. Time to catch up. It all seems to be there... Almost content-free except for the first post :-). Yes, the old definition was better. CLOCKS_PER_SEC is 18.2 in all the versions of Turbo/Burland C that I've looked at (1987-1999), but clock_t is long. Requiring CLOCKS_PER_SEC to have type clock_t breaks this. Requiring CLOCKS_PER_SEC to be a compile-time constant breaks my preferred definition of it as sysconf(...) :-), and is bad for portabilty as discussed in the thread. I suspect that there is a lot of practical code that does stupid things like revaluating CLOCKS_PER_SEC in inner loops, but I think this isn't much of a problem under BSDish system because serious code uses gettimeofday() or getrusage(). > > I actually prefer to let this rot and tell everyone to use clock_gettime(). > > We currently tell everyone to use getrusage(). I used to use gettimeofday() in my clock syscall overhead benchmark, but switched to clock_gettime() a few months ago when I finally got a system with a >= 1GHz clock :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 19:23:33 2002 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 634EC37B400; Tue, 28 May 2002 19:23:25 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g4T2NOEN009679; Tue, 28 May 2002 22:23:24 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g4T2NOMD009676; Tue, 28 May 2002 22:23:24 -0400 (EDT) Date: Tue, 28 May 2002 22:23:24 -0400 (EDT) From: Garrett Wollman Message-Id: <200205290223.g4T2NOMD009676@khavrinen.lcs.mit.edu> To: standards@freebsd.org Cc: jdp@freebsd.org Subject: Q&D implementation of dlfunc() Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Those who follow the Austin Group lists will be aware of an issue raised (and not resolved there) about the unsuitability of the return type of dlsym() for its most common use. Specifically, Standard C leaves undefined the result of converting a data pointer to a function pointer. Some compilers and lint programs may warn about doing this conversion, even though it is perfectly well-defined on all of the architectures FreeBSD supports. An alternate interface, dlfunc(), has been proposed to remedy this problem, by providing an alternate interface to dlsym() which returns a function pointer type. However, the POSIX committee is loath to add a new interface without some prior art. The following patch implements dlfunc() in order to provide that prior art. -GAWollman Index: include/dlfcn.h =================================================================== RCS file: /home/ncvs/src/include/dlfcn.h,v retrieving revision 1.14 diff -u -r1.14 dlfcn.h --- include/dlfcn.h 23 Mar 2002 17:24:53 -0000 1.14 +++ include/dlfcn.h 29 May 2002 02:05:42 -0000 @@ -63,10 +63,22 @@ void *dli_saddr; /* Address of nearest symbol */ } Dl_info; +/* + * The actual type declared by this typedef is immaterial, provided that + * it is a function pointer. Its purpose is to provide a return type for + * dlfunc() which can be cast to a function pointer type without depending + * on behavior undefined by the C standard which might trigger a compiler + * diagnostic. We intentionally declare a very unlikely type signature + * to force a diagnostic should the application not cast the return value + * of dlfunc() appropriately. + */ +typedef void (*__dlfunc_t)(void (*)(char, short, int, ...)); + __BEGIN_DECLS int dladdr(const void *, Dl_info *); int dlclose(void *); const char *dlerror(void); +__dlfunc_t dlfunc(void *, const char *); void dllockinit(void *_context, void *(*_lock_create)(void *_context), void (*_rlock_acquire)(void *_lock), Index: lib/libc/gen/Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/Makefile.inc,v retrieving revision 1.86 diff -u -r1.86 Makefile.inc --- lib/libc/gen/Makefile.inc 21 Mar 2002 06:45:32 -0000 1.86 +++ lib/libc/gen/Makefile.inc 29 May 2002 01:53:50 -0000 @@ -8,7 +8,7 @@ alarm.c arc4random.c assert.c basename.c \ clock.c closedir.c confstr.c \ crypt.c ctermid.c daemon.c devname.c dirname.c disklabel.c \ - dlfcn.c drand48.c erand48.c err.c errlst.c \ + dlfcn.c dlfunc.c drand48.c erand48.c err.c errlst.c \ exec.c fmtcheck.c fnmatch.c fstab.c ftok.c fts.c \ getbootfile.c getbsize.c \ getcap.c getcwd.c getdomainname.c getgrent.c getgrouplist.c \ Index: lib/libc/gen/dlopen.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/dlopen.3,v retrieving revision 1.19 diff -u -r1.19 dlopen.3 --- lib/libc/gen/dlopen.3 4 Feb 2002 10:44:15 -0000 1.19 +++ lib/libc/gen/dlopen.3 29 May 2002 02:11:10 -0000 @@ -32,11 +32,11 @@ .\" @(#) dlopen.3 1.6 90/01/31 SMI .\" $FreeBSD: src/lib/libc/gen/dlopen.3,v 1.19 2002/02/04 10:44:15 sobomax Exp $ .\" -.Dd September 24, 1989 +.Dd May 28, 2002 .Os .Dt DLOPEN 3 .Sh NAME -.Nm dlopen , dlsym , dlerror , dlclose +.Nm dlopen , dlsym , dlfunc , dlerror , dlclose .Nd programmatic interface to the dynamic linker .Sh LIBRARY .Lb libc @@ -46,6 +46,8 @@ .Fn dlopen "const char *path" "int mode" .Ft void * .Fn dlsym "void *handle" "const char *symbol" +.Ft __dlfunc_t +.Fn dlfunc "void *handle" "const char *symbol" .Ft const char * .Fn dlerror "void" .Ft int @@ -220,11 +222,28 @@ condition which may be queried with .Fn dlerror . .Pp +.Fn dlfunc +implements all of the behavior of +.Fn dlsym , +but has a return type which can be cast to a function pointer without +triggering compiler diagnostics. +.Po Fn dlsym +returns a data pointer; in the C standard, conversions between +data and function pointer types are undefined. Some compilers and +.Xr lint 1 +utilities warn about such casts. +.Pc +The precise return type of +.Fn dlfunc +is unspecified; applications must cast it to an appropriate function pointer +type. +.Pp .Fn dlerror returns a null-terminated character string describing the last error that occurred during a call to .Fn dlopen , .Fn dlsym , +.Fn dlfunc , or .Fn dlclose . If no such error has occurred, @@ -277,10 +296,11 @@ .Fl aout option to the C language compiler. .Sh ERRORS -.Fn dlopen +.Fn dlopen , +.Fn dlsym , and -.Fn dlsym -return the null pointer in the event of errors. +.Fn dlfunc +return a null pointer in the event of errors. .Fn dlclose returns 0 on success, or -1 if an error occurred. Whenever an error has been detected, a message detailing it can be --- /dev/null Tue May 28 22:11:01 2002 +++ lib/libc/gen/dlfunc.c Tue May 28 21:53:38 2002 @@ -0,0 +1,25 @@ +/* + * This source file is in the public domain. + * Garrett A. Wollman, 2002-05-28. + */ + +#include + +/* + * Implement the dlfunc() interface, which behaves exactly the same as + * dlsym() except that it returns a function pointer instead of a data + * pointer. This can be used by applications to avoid compiler warnings + * about undefined behavior, and is intended as prior art for future + * POSIX standardization. This function requires that all pointer types + * have the same representation, which is true on all platforms FreeBSD + * runs on, but is not guaranteed by the C standard. + */ +__dlfunc_t +dlfunc(void *handle, const char *symbol) +{ + __dlfunc_t rv; + + *(void **)&rv = dlsym(handle, symbol); + return (rv); +} + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 19:48:59 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by hub.freebsd.org (Postfix) with ESMTP id A348437B400; Tue, 28 May 2002 19:48:53 -0700 (PDT) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17CtW5-0000G3-00 (Debian); Wed, 29 May 2002 03:48:49 +0100 Date: Wed, 29 May 2002 03:48:49 +0100 From: Tony Finch To: Garrett Wollman Cc: standards@freebsd.org, jdp@freebsd.org Subject: Re: Q&D implementation of dlfunc() Message-ID: <20020529034849.A30428@chiark.greenend.org.uk> References: <200205290223.g4T2NOMD009676@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205290223.g4T2NOMD009676@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, May 28, 2002 at 10:23:24PM -0400 Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 28, 2002 at 10:23:24PM -0400, Garrett Wollman wrote: > Those who follow the Austin Group lists will be aware of an issue > raised (and not resolved there) about the unsuitability of the return > type of dlsym() for its most common use. They've also been arguing about it on comp.std.c. > +/* > + * The actual type declared by this typedef is immaterial, provided that > + * it is a function pointer. Its purpose is to provide a return type for > + * dlfunc() which can be cast to a function pointer type without depending > + * on behavior undefined by the C standard which might trigger a compiler > + * diagnostic. We intentionally declare a very unlikely type signature > + * to force a diagnostic should the application not cast the return value > + * of dlfunc() appropriately. > + */ > +typedef void (*__dlfunc_t)(void (*)(char, short, int, ...)); I'd be inclined to be less obfuscated by using a structure type to "guarantee" the uniqueness of the argument type of __dlfunc_t -- something like struct __dlfunc_arg { int dummy; }; typedef void (*__dlfunc_t)(struct __dlfunc_arg); and s/We .*/We use a unique structure as the argument type/. (The structure type could be made truly unique by declaring it in the argument list itself, but compilers will rightly warn about this since it makes the resulting function type unusable -- which is what we want except for the warning.) What does "Q&D" mean? Tony. -- f.a.n.finch http://dotat.at/ HEBRIDES BAILEY: CYCLONIC OR SOUTHEASTERLY BECOMING SOUTHWESTERLY, 4 OR 5, OCCASIONALLY 6 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 19:52:40 2002 Delivered-To: freebsd-standards@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 307DC37B401; Tue, 28 May 2002 19:52:36 -0700 (PDT) Date: Tue, 28 May 2002 19:52:36 -0700 From: "J. Mallett" To: Garrett Wollman Cc: standards@FreeBSD.org Subject: Re: Q&D implementation of dlfunc() Message-ID: <20020528195236.A66528@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I would prefer to see this done in a proper way, or at least have some suitably abstracted interface to allow MD pointer munging/indexing by these functions for the purpose of returning function pointers, however using our toolchain on all of our supported architectures, your change is somewhat straightforward enough, however I wonder if it wouldn't be better to write this: rv = (uintptr_t)dlsym(handle, symbol); But that's just the way I've taken to writing such shims, and your way is as valid as any, functionally, I suppose. I would say to write it like that, as you essentially synthesise the "correct" way to swap data and function pointer values, on all our architectures. Here are my conversion functions, stemming from a conversation with Bruce Evans a while ago: typedef void (*convptr)(); convptr function_to_data_ptr(convptr function, uintptr_t *data) { memcpy(data, &function, sizeof(convptr)); return function; } convptr data_to_function_ptr(convptr *function, uintptr_t *data) { memcpy(function, data, sizeof(convptr)); return *function; } -- J. Mallett FreeBSD: The Power To Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 20:32:44 2002 Delivered-To: freebsd-standards@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id D159737B403 for ; Tue, 28 May 2002 20:32:41 -0700 (PDT) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g4T3WZp56942; Tue, 28 May 2002 20:32:35 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020529034849.A30428@chiark.greenend.org.uk> Date: Tue, 28 May 2002 20:32:35 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Tony Finch Subject: Re: Q&D implementation of dlfunc() Cc: standards@freebsd.org, Garrett Wollman Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett, your patch looks fine to me. I do agree with Tony, though, that it would be better to use a unique struct as the argument. Actually I think I'd prefer a pointer to the unique struct, but it doesn't really make any difference. Tony Finch wrote: > What does "Q&D" mean? Probably quick & dirty. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 20:40:59 2002 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C3A8C37B403; Tue, 28 May 2002 20:40:53 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g4T3erEN010141; Tue, 28 May 2002 23:40:53 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g4T3erxr010138; Tue, 28 May 2002 23:40:53 -0400 (EDT) Date: Tue, 28 May 2002 23:40:53 -0400 (EDT) From: Garrett Wollman Message-Id: <200205290340.g4T3erxr010138@khavrinen.lcs.mit.edu> To: "J. Mallett" Cc: standards@FreeBSD.ORG Subject: Re: Q&D implementation of dlfunc() In-Reply-To: <20020528195236.A66528@FreeBSD.ORG> References: <20020528195236.A66528@FreeBSD.ORG> Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > rv = (uintptr_t)dlsym(handle, symbol); For the same reason as you can't cast from a data pointer to a function pointer, there's no guarantee that you can cast from a uintptr_t (if such a type even exists) to a function pointer. Since we're depending on all pointers having the same representation, I'd rather make it explicit. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 20:43:53 2002 Delivered-To: freebsd-standards@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 79EF937B401; Tue, 28 May 2002 20:43:50 -0700 (PDT) Date: Tue, 28 May 2002 20:43:50 -0700 From: "J. Mallett" To: Garrett Wollman Cc: standards@FreeBSD.ORG Subject: Re: Q&D implementation of dlfunc() Message-ID: <20020528204350.B74072@FreeBSD.ORG> References: <20020528195236.A66528@FreeBSD.ORG> <200205290340.g4T3erxr010138@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200205290340.g4T3erxr010138@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, May 28, 2002 at 11:40:53PM -0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , X-Affiliated-Projects: FreeBSD, xMach, ircd-hybrid-7 X-Towel: Yes Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * From Garrett Wollman > < said: > > > rv = (uintptr_t)dlsym(handle, symbol); > > For the same reason as you can't cast from a data pointer to a > function pointer, there's no guarantee that you can cast from a > uintptr_t (if such a type even exists) to a function pointer. Since > we're depending on all pointers having the same representation, I'd > rather make it explicit. Right, I understand the situation, and how evil it is. Look at the code I put below, I think I forgot to include parts of my hello world, which removes that assumption, by doing (note inocrrectness of hello was to deal with having prototypes in scope, I could have done something cleaner, but...): convptr hello(convptr function, uintptr_t *data) { printf("## hello: %p, %p\n", function, data); printf("Hello, world!\n"); return function; } int main(int argc, char *argv[]) { convptr foo, bar; uintptr_t data[sizeof(convptr)/sizeof(uintptr_t)]; printf("## main: 0x%x, %p\n", argc, argv); function_to_data_ptr((convptr)data_to_function_ptr, data); data_to_function_ptr(&foo, data); function_to_data_ptr((convptr)hello, data); (*foo)(&bar, data); (*bar)(NULL, NULL); return 0; } -- J. Mallett FreeBSD: The Power To Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 21: 0:59 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by hub.freebsd.org (Postfix) with ESMTP id DA2FF37B405 for ; Tue, 28 May 2002 21:00:54 -0700 (PDT) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17Cudm-0001b9-00 (Debian); Wed, 29 May 2002 05:00:50 +0100 Date: Wed, 29 May 2002 05:00:50 +0100 From: Tony Finch To: John Polstra Cc: Tony Finch , standards@freebsd.org, Garrett Wollman Subject: Re: Q&D implementation of dlfunc() Message-ID: <20020529050050.B30428@chiark.greenend.org.uk> References: <20020529034849.A30428@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdp@polstra.com on Tue, May 28, 2002 at 08:32:35PM -0700 Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 28, 2002 at 08:32:35PM -0700, John Polstra wrote: > Garrett, your patch looks fine to me. I do agree with Tony, though, > that it would be better to use a unique struct as the argument. > Actually I think I'd prefer a pointer to the unique struct, but it > doesn't really make any difference. It does -- consider the following: void *p = malloc(10); dlfunc(NULL, "free")(p); Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: EAST OR SOUTHEAST 4 OR 5, OCCASIONALLY 6 LATER. RAIN OR SHOWERS. MODERATE, OCCASIONALLY POOR. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue May 28 21: 3:58 2002 Delivered-To: freebsd-standards@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 4B0E637B400 for ; Tue, 28 May 2002 21:03:55 -0700 (PDT) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g4T43op57073; Tue, 28 May 2002 21:03:50 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020529050050.B30428@chiark.greenend.org.uk> Date: Tue, 28 May 2002 21:03:50 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Tony Finch Subject: Re: Q&D implementation of dlfunc() Cc: Garrett Wollman , standards@freebsd.org Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tony Finch wrote: > On Tue, May 28, 2002 at 08:32:35PM -0700, John Polstra wrote: >> Actually I think I'd prefer a pointer to the unique struct, but it >> doesn't really make any difference. > > It does -- consider the following: > > void *p = malloc(10); > dlfunc(NULL, "free")(p); Yep, you're right. I plead C++ brain pollution. :-} John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu May 30 6:44:55 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by hub.freebsd.org (Postfix) with ESMTP id 37EF937B400 for ; Thu, 30 May 2002 06:44:51 -0700 (PDT) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 17DQES-0007iK-00 (Debian); Thu, 30 May 2002 14:44:48 +0100 Date: Thu, 30 May 2002 14:44:48 +0100 From: Tony Finch To: Bruce Evans Cc: Tony Finch , freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization Message-ID: <20020530144448.C621@chiark.greenend.org.uk> References: <20020528191650.A8322@chiark.greenend.org.uk> <20020529051638.F22456-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529051638.F22456-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, May 29, 2002 at 05:56:17AM +1000 Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 29, 2002 at 05:56:17AM +1000, Bruce Evans wrote: > On Tue, 28 May 2002, Tony Finch wrote: > > > I noticed that clock(3) currently violates a requirement of POSIX > > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > > are inconsistent and somtimes different from what is in clocks(7). > > That is only in a (broken) XSI extension. "Fixing" this would mainly > break binary compatibility since it would change from one historical > wrong value to another (128 -> 1000000). The first C standard got this > right by permitting it to be a runtime parameter. This value should > be which may be a few billion on > current machines. This requires clock_t to be much larger than uint32_t > so that it can represent 24 hours in ticks. clock_t should probably be > double. Hmm, I've been thinking about this a bit more. Does FreeBSD actually keep the necessary statistics at that resolution? As far as I can tell it is done internally at microsecond resolution. Tony. -- f.a.n.finch http://dotat.at/ LUNDY: SOUTHWESTERLY 5 OR 6 DECREASING 3 OR 4. SHOWERS. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu May 30 9:56: 0 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D58FB37B401 for ; Thu, 30 May 2002 09:55:57 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA02121; Fri, 31 May 2002 02:55:49 +1000 Date: Fri, 31 May 2002 02:59:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Tony Finch Cc: freebsd-standards@FreeBSD.ORG Subject: Re: clock(3) standardization In-Reply-To: <20020530144448.C621@chiark.greenend.org.uk> Message-ID: <20020531024719.V29640-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 30 May 2002, Tony Finch wrote: > On Wed, May 29, 2002 at 05:56:17AM +1000, Bruce Evans wrote: > > On Tue, 28 May 2002, Tony Finch wrote: > > > > > I noticed that clock(3) currently violates a requirement of POSIX > > > 2001 (that CLOCKS_PER_SEC is 1000000) and that the various archs > > > are inconsistent and somtimes different from what is in clocks(7). > > > > That is only in a (broken) XSI extension. "Fixing" this would mainly > > break binary compatibility since it would change from one historical > > wrong value to another (128 -> 1000000). The first C standard got this > ... > Hmm, I've been thinking about this a bit more. Does FreeBSD actually > keep the necessary statistics at that resolution? As far as I can > tell it is done internally at microsecond resolution. It does now, more or less. Process times are stored in struct bintime in -current. struct bintime has a resolution of 2^-64 seconds. User, sys and interrupt times are the process time split up statistically (so their accuracy is much lower than the resolution). This only affects getrusage() and similar interfaces. clock() could use timecounters directly and get the 2^-64 resolution, but there is currently no syscall for this. clock_gettime() is closest. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message