From owner-freebsd-standards@FreeBSD.ORG Mon May 9 11:07:15 2011 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4D9106567C for ; Mon, 9 May 2011 11:07:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 737608FC13 for ; Mon, 9 May 2011 11:07:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p49B7Fk6070755 for ; Mon, 9 May 2011 11:07:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p49B7EX3070753 for freebsd-standards@FreeBSD.org; Mon, 9 May 2011 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 May 2011 11:07:14 GMT Message-Id: <201105091107.p49B7EX3070753@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 11:07:15 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/154842 standards invalid request authenticator in the second and subseq o stand/150093 standards C++ std::locale support is broken a stand/149980 standards [libc] [patch] negative value integer to nanosleep(2) o stand/147210 standards xmmintrin.h and cstdlib conflicts with each other with o docs/143472 standards gethostname(3) references undefined value: HOST_NAME_M s stand/141705 standards [libc] [request] libc lacks cexp (and friends) o stand/130067 standards Wrong numeric limits in system headers? o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/56476 standards [patch] cd9660 unicode support simple hack o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 35 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon May 9 21:20:29 2011 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DF72106564A for ; Mon, 9 May 2011 21:20:29 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E50708FC0A for ; Mon, 9 May 2011 21:20:28 +0000 (UTC) Received: by wwc33 with SMTP id 33so5832637wwc.31 for ; Mon, 09 May 2011 14:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=OMylmStRka+/Vy6EJsase32xcYH38k/e29LiUMV+mH0=; b=kunb5dJUbr2kLV1SbS0rpjkZhYkycqvzmnHyS8xRxSvVQsQPFI+5XWf1huOrPuOhrt bjmXOXDd4nD5ie6r1BLrfVIEkrfwZyVfmQu/mOwoQvwxLHebnphHV+Fe57YZgwbpJSlR wr6TF4ndmhdDOWVMSsfH1Kw/Y3mypigCd6ks0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; b=H5p34PnD3fcZavZWlOmzuDibUPcqLZM7UIsSJ+8J3uFm2XcO+1BArNAIM1k98nOrUo fTkxUnVqa44gjckARa7Ccy+Lg/shi4euXK8KmruxqnIwRMIwgX1uyHFk+blRzj8O2V71 ndfVVOB+P6vWOVsAU352SHLy2f19odAlYbkig= Received: by 10.216.236.157 with SMTP id w29mr92849weq.18.1304968396080; Mon, 09 May 2011 12:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.48.207 with HTTP; Mon, 9 May 2011 12:12:46 -0700 (PDT) In-Reply-To: <20110325033736.GA64512@zim.MIT.EDU> References: <201103221457.p2MEvJub035858@lurza.secnetix.de> <20110322181604.GA47588@zim.MIT.EDU> <20110325033736.GA64512@zim.MIT.EDU> From: Chris Rees Date: Mon, 9 May 2011 20:12:46 +0100 Message-ID: To: Eitan Adler , utisoft@gmail.com, Maxim Konovalov , Oliver Fromme , FreeBSD Standards Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: dd dies on SIGUSR1 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 21:20:29 -0000 On 25 March 2011 03:37, David Schultz wrote: > On Wed, Mar 23, 2011, Eitan Adler wrote: >> > We are talking about a design decision taken decades ago, which quite >> > possibly was a mistake. >> >> Historical reasons are not be discounted, but in this case because the >> behavior is already non-portable, and already not be relied upon, so >> there is no reason that changing the default is harmful. >> >> > Again, how many people rely on USR1 to terminate a process? >> >> Hopefully none. Even if there are people who do rely on such behavior >> that reliance could be said to be a mistake or otherwise broken. > > Please see my previous message. =A0The historical behavior of SIGUSR1 > terminating a process by default is standard, even on Linux. > > I believe one of the original uses of the signal was to allow > daemons and their children to signal each other. =A0In this use > case, if the notification can't be delivered because the recipient > is unprepared to accept it, termination is appropriate for a > fail-fast design. Since the consensus seems to be for leaving as-is, perhaps someone could please close bin/155034? You can state that I've abandoned it! Chris From owner-freebsd-standards@FreeBSD.ORG Mon May 9 23:04:51 2011 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AC41065753 for ; Mon, 9 May 2011 23:04:51 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id E86738FC31 for ; Mon, 9 May 2011 23:04:50 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p49MT25X018446; Mon, 9 May 2011 18:29:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p49MT1Wr018445; Mon, 9 May 2011 18:29:01 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 9 May 2011 18:29:01 -0400 From: David Schultz To: Chris Rees Message-ID: <20110509222901.GA18428@zim.MIT.EDU> Mail-Followup-To: Chris Rees , Eitan Adler , Maxim Konovalov , Oliver Fromme , FreeBSD Standards References: <201103221457.p2MEvJub035858@lurza.secnetix.de> <20110322181604.GA47588@zim.MIT.EDU> <20110325033736.GA64512@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: FreeBSD Standards , Maxim Konovalov , Oliver Fromme Subject: Re: dd dies on SIGUSR1 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:04:51 -0000 On Mon, May 09, 2011, Chris Rees wrote: > On 25 March 2011 03:37, David Schultz wrote: > > On Wed, Mar 23, 2011, Eitan Adler wrote: > >> > We are talking about a design decision taken decades ago, which quite > >> > possibly was a mistake. > >> > >> Historical reasons are not be discounted, but in this case because the > >> behavior is already non-portable, and already not be relied upon, so > >> there is no reason that changing the default is harmful. > >> > >> > Again, how many people rely on USR1 to terminate a process? > >> > >> Hopefully none. Even if there are people who do rely on such behavior > >> that reliance could be said to be a mistake or otherwise broken. > > > > Please see my previous message.  The historical behavior of SIGUSR1 > > terminating a process by default is standard, even on Linux. > > > > I believe one of the original uses of the signal was to allow > > daemons and their children to signal each other.  In this use > > case, if the notification can't be delivered because the recipient > > is unprepared to accept it, termination is appropriate for a > > fail-fast design. > > Since the consensus seems to be for leaving as-is, perhaps someone > could please close bin/155034? > > You can state that I've abandoned it! Looking into the solution originally proposed is still on my todo list... In researching it further, I noticed that even Linux doesn't support this convention consistently: Most utilities die on receipt of SIGUSR1, or fail to do anything useful. dd appears to be the sole exception.