From owner-cvs-src@FreeBSD.ORG Wed Mar 16 02:44:12 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0A8016A4CE; Wed, 16 Mar 2005 02:44:12 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EC4643D48; Wed, 16 Mar 2005 02:44:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j2G2iBHn004696; Wed, 16 Mar 2005 13:44:11 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j2G2i8S5008558; Wed, 16 Mar 2005 13:44:10 +1100 Date: Wed, 16 Mar 2005 13:44:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <200503151553.j2FFrdeF075515@repoman.freebsd.org> Message-ID: <20050316134243.M69441@delplex.bde.org> References: <200503151553.j2FFrdeF075515@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/share/man/man3 Makefile src/lib/libc/alpha/gen Makefile.inc fpsetsticky.c src/lib/libc/amd64/gen Makefile.inc fpsetsticky.c src/lib/libc/powerpc/gen Makefile.inc fpsetsticky.c src/lib/libc/softfloat Makefile.inc src/lib/libc/sparc64/gen ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 02:44:13 -0000 On Tue, 15 Mar 2005, David Schultz wrote: > ... > Log: > Remove fpsetsticky(). This was added for SysV compatibility, but due > to mistakes from day 1, it has always had semantics inconsistent with > SVR4 and its successors. In particular, given argument M: > ... > There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps > and apps ported from other operating systems, so the best approach > seems to be to kill the function and fix any apps that break. I > ... > PR: 75862 > Suggested by: bde Thanks. Bruce