From owner-cvs-lib Sun Apr 2 12:37:04 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA08964 for cvs-lib-outgoing; Sun, 2 Apr 1995 12:37:04 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA08929; Sun, 2 Apr 1995 12:35:41 -0700 Date: Sun, 2 Apr 1995 12:35:41 -0700 From: "Andrey A. Chernov" Message-Id: <199504021935.MAA08929@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/nls Makefile.inc Sender: cvs-lib-owner@freebsd.org Precedence: bulk ache 95/04/02 12:35:41 Modified: lib/libc/nls Makefile.inc Log: Fix manpage rule From owner-cvs-lib Sun Apr 2 12:59:53 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA09313 for cvs-lib-outgoing; Sun, 2 Apr 1995 12:59:53 -0700 Received: (from wpaul@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA09230; Sun, 2 Apr 1995 12:58:30 -0700 Date: Sun, 2 Apr 1995 12:58:30 -0700 From: Bill Paul Message-Id: <199504021958.MAA09230@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/yp xdryp.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk wpaul 95/04/02 12:58:30 Modified: lib/libc/yp xdryp.c Log: Fix xdr_ypmap_parms() so that it agrees with xdr_domainname(), xdr_peername() and friends. From owner-cvs-lib Sun Apr 2 13:07:03 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA09604 for cvs-lib-outgoing; Sun, 2 Apr 1995 13:07:03 -0700 Received: (from wpaul@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA09568; Sun, 2 Apr 1995 13:05:26 -0700 Date: Sun, 2 Apr 1995 13:05:26 -0700 From: Bill Paul Message-Id: <199504022005.NAA09568@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/rpc clnt_udp.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk wpaul 95/04/02 13:05:24 Modified: lib/libc/rpc clnt_udp.c Log: Submitted by: Sebastian Strollow Obtained from: Casper H. Dik (by vay of Usenet) Small patch to help improve NIS rebinding times (among other things): >From: casper@fwi.uva.nl (Casper H.S. Dik) >Newsgroups: comp.sys.sun.misc,comp.sys.sun.admin >Subject: FIX for slow rebinding of NIS. >Summary: a small change in libc makes life with NIS a lot easier. >Message-ID: <1992Jan17.173905.11727@fwi.uva.nl> >Date: 17 Jan 92 17:39:05 GMT >Sender: news@fwi.uva.nl >Organization: FWI, University of Amsterdam >Lines: 138 >Nntp-Posting-Host: halo.fwi.uva.nl Have you been plagued by long waits when your NIS server is rebooted? READ ON! Sun has a patch, but the README says: ********************* WARNING ****************************** This is a new version of ypbind that never uses the NIS binding file to cache the servers binding. This will have the effect of fixing the current symptom. However, it might degrade the overall performance of the system when the server is available. This is most likely to happen on an overloaded server, which will cause the network to produce a broadcast storm. ************************************************************* Therefor, I have produced another fix. o What goes wrong. When the NIS server is rebooted, ypserv will obtain different ports to listen for RPC requests. All clients will continue to use the old binding they obtained earlier. The NIS server will send ICMP dst unreachable messages for the RPC requests that arrive at the old port. These ICMPs are dropped on the floor and the client code will continue sending the requests until the timer has expired. The small fix at the end of this message will pick up these ICMP messages and deliver them to the RPC layer. o Before and after. I've tested this on some machines and this is the result: (kill and restart ypserv on the server) original% time ypmatch user passwd user:.... 0.040u 0.090s 2:35.64 0.0% 0+126k 0+0io 0pf+0w (155 seconds elapsed time) fixedhost% time ypmatch user passwd user:.... 0.050u 0.050s 0:10.20 0.9% 0+136k 0+0io 0pf+0w (10 seconds elapsed time) Rebinding is almost instantaneous. o Other benefits. RPC calls that use UDP as transport will no longer time out but will abort much sooner. (E.g., the remote host is unreachable or 111/udp is filtered by an intermediate router) From owner-cvs-lib Mon Apr 3 18:28:04 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA26042 for cvs-lib-outgoing; Mon, 3 Apr 1995 18:28:04 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA25999; Mon, 3 Apr 1995 18:27:57 -0700 Date: Mon, 3 Apr 1995 18:27:57 -0700 From: "Andrey A. Chernov" Message-Id: <199504040127.SAA25999@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/sys select.2 Sender: cvs-lib-owner@freebsd.org Precedence: bulk ache 95/04/03 18:27:56 Modified: lib/libc/sys select.2 Log: Properly describe how to expand default limit of handled descriptors From owner-cvs-lib Mon Apr 3 22:36:27 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03818 for cvs-lib-outgoing; Mon, 3 Apr 1995 22:36:27 -0700 Received: (from wpaul@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03808; Mon, 3 Apr 1995 22:36:18 -0700 Date: Mon, 3 Apr 1995 22:36:18 -0700 From: Bill Paul Message-Id: <199504040536.WAA03808@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/gen getgrent.c getnetgrent.c getpwent.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk wpaul 95/04/03 22:36:17 Modified: lib/libc/gen getgrent.c getnetgrent.c getpwent.c Log: getpwent.c: fix problem with emacs dumping core when NIS is enabled. Also add #includes for YP headers when compiling with -DYP to avoid some implicit declarations. getgrent.c & getnetgrent.c: add some #includes to avoid implicit declarations of YP functions. From owner-cvs-lib Mon Apr 3 22:53:29 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04181 for cvs-lib-outgoing; Mon, 3 Apr 1995 22:53:29 -0700 Received: (from wpaul@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA04169; Mon, 3 Apr 1995 22:53:24 -0700 Date: Mon, 3 Apr 1995 22:53:24 -0700 From: Bill Paul Message-Id: <199504040553.WAA04169@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/rpc rpc_dtablesize.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk wpaul 95/04/03 22:53:23 Modified: lib/libc/rpc rpc_dtablesize.c Log: 'Fix' for esoteric misfeature discovered while searching for another bug: select() returns EINVAL if you try to feed it a value of FD_SETSIZE greater that 256. You can apparently adjust this by specifying a larger value of FD_SETSIZE when configuring your kernel. However, if you set the maximum number of open file descriptors per process to some value greater than the FD_SETSIZE value that select() expects, many selects() within the RPC library code will be botched because _rpc_dtablesize() will return invalid numbers. This is to say that it will return the upper descriptor table size limit which can be much higher than 256. Unless select() is prepared to expect this 'unusually' high value, it will fail. (A good example of this can be seen with NIS enabled: if you type 'unlimit' at the shell prompt and then run any command that does NIS calls, you'll be bombarded with errors from clnttcp_create().) A temporary fix for this is to clamp the value returned by _rpc_dtablesize() at FD_SETSIZE (as defined in (256)). I suppose the Right Thing would be to provide some mechanism for select() to dynamically adjust itself to handle FD_SETSIZE values larger than 256, but it's a bit late in the game for that. Hopefully 256 file descriptors will be enough to keep RPC happy for now. From owner-cvs-lib Tue Apr 4 01:24:34 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA06982 for cvs-lib-outgoing; Tue, 4 Apr 1995 01:24:34 -0700 Received: from mpp.com (dialup-1-73.gw.umn.edu [134.84.101.73]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id BAA06927; Tue, 4 Apr 1995 01:24:15 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id DAA08121; Tue, 4 Apr 1995 03:21:54 -0500 From: Mike Pritchard Message-Id: <199504040821.DAA08121@mpp.com> Subject: Re: cvs commit: src/lib/libc/rpc rpc_dtablesize.c To: wpaul@freefall.cdrom.com (Bill Paul) Date: Tue, 4 Apr 1995 03:21:53 -0500 (CDT) Cc: CVS-commiters@freefall.cdrom.com, cvs-lib@freefall.cdrom.com In-Reply-To: <199504040553.WAA04169@freefall.cdrom.com> from "Bill Paul" at Apr 3, 95 10:53:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4021 Sender: cvs-lib-owner@freebsd.org Precedence: bulk > A temporary fix for this is to clamp the value returned by _rpc_dtablesize() > at FD_SETSIZE (as defined in (256)). I suppose the Right > Thing would be to provide some mechanism for select() to dynamically > adjust itself to handle FD_SETSIZE values larger than 256, but it's a > bit late in the game for that. Hopefully 256 file descriptors will be enough > to keep RPC happy for now. I've done some work directly related to this in the past. You run into problems anytime the user is able to raise the open file limit higher than FD_SETSIZE. Just so everyone knows, the problem is that whenever the open file limit is higher than FD_SETSIZE, and select() is called and given an "nfds" parmeter > FD_SETSIZE, select winds up reading past the fdset array and finds bogus bits set and usually blows the system call off with EBADF. Programs really shouldn't be calling select with a "nfds" parameter of "getdtablesize()", they should use FD_SETSIZE instead. On the system I was working on, we had users who wanted to be able to have 10,000+ open files at a time (don't ask me why - I personally think that if you require that many open files you must be doing something really stupid/inefficient). After a lot of heated discussion, we decided to set FD_SETSIZE to 1024 so that most compiled programs would be able to handle almost any "reasonable" open file limit they might be run with and document the fact that higher limits would probably require changes to allow the program to correctly in all cases when using the higher limit. In order to allow programs with > 1024 open files to use a select like function, we opted to implement the SYS5.4 "poll" system call. You those of you who aren't familiar with poll(), it allows you to pass in an array of file descriptors that you want polled (for the same conditions that select checks). This has the advantage of allowing the user to check file descriptors > FD_SETSIZE, and since most programs are usually only interested in a few file descriptors anyways, no extra kernel overhead is involved scanning a bitmask full of zeros that you aren't interested in. System library routines can then be changed to use poll() so that they will function no matter how many open files the calling program may have opened. Any program that requires more than FD_SETSIZE open files needs to be aware of the fact that they need to use poll() instead of select. Select() could also be implemented as a library routine that calls poll() if so desired. Standard I/O also needs to allow support of the higher number of open file. I think that the current FreeBSD stdio does dynamic allocation of the FILE structure entries at run time so I don't think that this is a problem. POSIX doesn't say anything about select/poll, either. But POSIX does take a stand on several issues on the maximum number of open files. One of them being the fact that the maximum number of open files per process can't change over the life of the process, which FreeBSD currently violates. The fix for this is to allow a "new" limit to be set that is inherited by any new child processes that are created, but the limit for the process that set the limit is not changed. POSIX also has some things to say about the OPEN_MAX symbol (if it is defined then certain things must be a certain way, and that if it is not defined then certain things can work another way, I forget the exact details), and something about a minimum number of open files (OPEN_MIN?). I don't have a POSIX manual handy, so I can't be anymore specific right now. The ANSI C spec also has something to say about OPEN_MAX. The whole problem with this is that if you really want to be able to support large numbers of open files correctly and in a POSIX blessed manner, you have to bite the bullet and make some decisions on which way you want the open file limit handled. -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn" From owner-cvs-lib Tue Apr 4 04:29:58 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA10657 for cvs-lib-outgoing; Tue, 4 Apr 1995 04:29:58 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA10643; Tue, 4 Apr 1995 04:29:52 -0700 Date: Tue, 4 Apr 1995 04:29:52 -0700 From: "Andrey A. Chernov" Message-Id: <199504041129.EAA10643@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/sys select.2 Sender: cvs-lib-owner@freebsd.org Precedence: bulk ache 95/04/04 04:29:52 Modified: lib/libc/sys select.2 Log: Add "before inclusion of any header which ... " Suggested by: bde From owner-cvs-lib Tue Apr 4 09:09:36 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA14854 for cvs-lib-outgoing; Tue, 4 Apr 1995 09:09:36 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA14839; Tue, 4 Apr 1995 09:08:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA26586; Wed, 5 Apr 1995 02:05:38 +1000 Date: Wed, 5 Apr 1995 02:05:38 +1000 From: Bruce Evans Message-Id: <199504041605.CAA26586@godzilla.zeta.org.au> To: pritc003@maroon.tc.umn.edu, wpaul@freefall.cdrom.com Subject: Re: cvs commit: src/lib/libc/rpc rpc_dtablesize.c Cc: CVS-commiters@freefall.cdrom.com, cvs-lib@freefall.cdrom.com Sender: cvs-lib-owner@freebsd.org Precedence: bulk >> A temporary fix for this is to clamp the value returned by _rpc_dtablesize() >> at FD_SETSIZE (as defined in (256)). I suppose the Right >> Thing would be to provide some mechanism for select() to dynamically >> adjust itself to handle FD_SETSIZE values larger than 256, but it's a >> bit late in the game for that. Hopefully 256 file descriptors will be enough >> to keep RPC happy for now. >I've done some work directly related to this in the past. You run >into problems anytime the user is able to raise the open file limit >higher than FD_SETSIZE. Just so everyone knows, the problem is >that whenever the open file limit is higher than FD_SETSIZE, and >select() is called and given an "nfds" parmeter > FD_SETSIZE, select >winds up reading past the fdset array and finds bogus bits set and >usually blows the system call off with EBADF. Programs really shouldn't >be calling select with a "nfds" parameter of "getdtablesize()", >they should use FD_SETSIZE instead. FreeBSD avoids the EBADF problem by rejecting the select() if `nfds' is too hard. It has to, because it copies the user fd_set structs to local variables, and it can't afford to write past the end of the copies. The code is: if (uap->nd > FD_SETSIZE) return (EINVAL); if (uap->nd > p->p_fd->fd_nfiles) uap->nd = p->p_fd->fd_nfiles; /* forgiving; slightly wrong */ How about this instead: if (uap->nd > p->p_fd->fd_nfiles) uap->nd = p->p_fd->fd_nfiles; /* forgiving; slightly wrong */ if (uap->nd > FD_SETSIZE) return (EINVAL); >POSIX doesn't say anything about select/poll, either. But POSIX does >take a stand on several issues on the maximum number of open files. >One of them being the fact that the maximum number of open files per process >can't change over the life of the process, which FreeBSD currently violates. >The fix for this is to allow a "new" limit to be set that is inherited by >any new child processes that are created, but the limit for the process that >set the limit is not changed. Someone broke this some more by introducing the sysctl variable `kern.maxfilesperproc'. What systems implement "new" limits? >POSIX also has some things to say about the OPEN_MAX symbol (if it is >defined then certain things must be a certain way, and that if >it is not defined then certain things can work another way, I forget >the exact details), and something about a minimum number of open files >(OPEN_MIN?). I don't have a POSIX manual handy, so I can't be anymore >specific right now. The ANSI C spec also has something to say about >OPEN_MAX. There's no OPEN_MIN. FreeBSD violates POSIX by defining OPEN_MAX when the max is variable. Many programs expect OPEN_MAX and NOFILE to be constant so it's pragmatic to define it as a constant. Bruce From owner-cvs-lib Tue Apr 4 11:12:32 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA18071 for cvs-lib-outgoing; Tue, 4 Apr 1995 11:12:32 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA18019; Tue, 4 Apr 1995 11:11:03 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id UAA13035; Tue, 4 Apr 1995 20:04:09 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199504041804.UAA13035@gvr.win.tue.nl> Subject: Re: cvs commit: src/lib/libc/rpc rpc_dtablesize.c To: bde@zeta.org.au (Bruce Evans) Date: Tue, 4 Apr 1995 20:04:09 +0200 (MET DST) Cc: pritc003@maroon.tc.umn.edu, wpaul@freefall.cdrom.com, CVS-commiters@freefall.cdrom.com, cvs-lib@freefall.cdrom.com In-Reply-To: <199504041605.CAA26586@godzilla.zeta.org.au> from "Bruce Evans" at Apr 5, 95 02:05:38 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 307 Sender: cvs-lib-owner@freebsd.org Precedence: bulk > > Someone broke this some more by introducing the sysctl variable > `kern.maxfilesperproc'. What systems implement "new" limits? > I did to be able to protect yourself against ppl eating up *all* files in a system. We've had such jokers, and there is nothing you can do about it, except this. -Guido From owner-cvs-lib Wed Apr 5 08:39:57 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA22899 for cvs-lib-outgoing; Wed, 5 Apr 1995 08:39:57 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA22881 ; Wed, 5 Apr 1995 08:39:29 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA23814; Thu, 6 Apr 1995 01:36:31 +1000 Date: Thu, 6 Apr 1995 01:36:31 +1000 From: Bruce Evans Message-Id: <199504051536.BAA23814@godzilla.zeta.org.au> To: bde@zeta.org.au, guido@gvr.win.tue.nl Subject: Re: cvs commit: src/lib/libc/rpc rpc_dtablesize.c Cc: CVS-commiters@freefall.cdrom.com, cvs-lib@freefall.cdrom.com, pritc003@maroon.tc.umn.edu, wpaul@freefall.cdrom.com Sender: cvs-lib-owner@freebsd.org Precedence: bulk >> >> Someone broke this some more by introducing the sysctl variable >> `kern.maxfilesperproc'. What systems implement "new" limits? >> >I did to be able to protect yourself against ppl eating up *all* >files in a system. We've had such jokers, and there is nothing you can do >about it, except this. You can hack init or login to set the hard resource limit. Bruce From owner-cvs-lib Wed Apr 5 15:56:50 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA04177 for cvs-lib-outgoing; Wed, 5 Apr 1995 15:56:50 -0700 Received: (from joerg@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA04163 ; Thu, 6 Apr 1995 00:56:47 +0200 Date: Thu, 6 Apr 1995 00:56:47 +0200 From: Joerg Wunsch Message-Id: <199504052256.AAA04163@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/gen setmode.3 Sender: cvs-lib-owner@freebsd.org Precedence: bulk joerg 95/04/06 00:56:47 Modified: lib/libc/gen setmode.3 Log: The man page setmode(3) declares `void setmode' when it should be declared `void *setmode'. Submitted by: kargl@troutmask.apl.washington.edu From owner-cvs-lib Thu Apr 6 09:28:20 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA01486 for cvs-lib-outgoing; Thu, 6 Apr 1995 09:28:20 -0700 Received: (from bde@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA01476 ; Thu, 6 Apr 1995 09:28:18 -0700 Date: Thu, 6 Apr 1995 09:28:18 -0700 From: Bruce Evans Message-Id: <199504061628.JAA01476@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/stdio vfprintf.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk bde 95/04/06 09:28:17 Modified: lib/libc/stdio vfprintf.c Log: Obtained from: 1.1.5 (originally by jtc) Fix printf("%g", 0.0) - print "0", not "0.". The previous fixes in this area had one non-cosmetic (non-)change that caused this bug. Bruce From owner-cvs-lib Fri Apr 7 04:52:25 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA04350 for cvs-lib-outgoing; Fri, 7 Apr 1995 04:52:25 -0700 Received: (from bde@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA04340 ; Fri, 7 Apr 1995 04:52:19 -0700 Date: Fri, 7 Apr 1995 04:52:19 -0700 From: Bruce Evans Message-Id: <199504071152.EAA04340@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/locale isctype.c nomacros.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk bde 95/04/07 04:52:18 Modified: include ctype.h Log: Reviewed by: ache and wollman (long ago) Fix numerous ANSI conformance bugs and other nits. ctype.h: o There were no prototypes behind the macros (conformance bug). o isascii() didn't have enough parentheses (plain bug). o tolower() and toupper were always static inline (conformance bug? You could undef them and take their address, but this gave different addresses in different modules. You couldn't undef them and declare them (correctly) again). 's treatment of putc() shows one way to handle this problem, but it only works because the putc() macro is allowed to reevaluate its args. I used a hack controlled by _EXTERNALIZE_CTYPE_INLINES_ to get to generate the code (the previous hack involving _ANSI_LIBRARY_ goes away). This has the advantage that the core of the functions is only written down once and the disadvantage that another layer of functions is required. The extra layer goes away if inline functions are used, leaving only the problem of understanding why there are functions named toupper(), __toupper and ___toupper() as well as a macro named toupper. o Nothing seems to define _USE_CTYPE_LIBRARY_. Eliminate it o Let the user set _USE_CTYPE_INLINE_ and _DONT_USE_CTYPE_INLINE_ for full control over inlining. o The args for the inline functions didn't have enough underscores (conformance bug). o The formatting and ordering was inconsistent (style bug). o TODO: fix conformance bugs brought by including . Modified: lib/libc/locale isctype.c nomacros.c Log: Reviewed by: ache and wollman (long ago) isctype.c: o The tolower() and toupper() functions duplicated too much code and were out of date (surprise). This didn't matter because it was difficult to call them. o Change formatting to be more like that in (with extra parentheses as in the macros). Perhaps this file should be machine generated or everything should be handled like __tolower() so that no code is repeated. nomacros.c: o Instead of looking at _USE_CTYPE_INLINE_ to see what has done, set _EXTERNALIZE_CTYPE_INLINES_ to tell what to do, so that we don't have anything left to do. Note that code is now generated even if inlines are used by default. This allows users to switch to non-inline versions. From owner-cvs-lib Fri Apr 7 16:13:51 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA22939 for cvs-lib-outgoing; Fri, 7 Apr 1995 16:13:51 -0700 Received: (from bde@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA22928 ; Fri, 7 Apr 1995 16:13:44 -0700 Date: Fri, 7 Apr 1995 16:13:44 -0700 From: Bruce Evans Message-Id: <199504072313.QAA22928@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/msun/src e_jn.c e_jnf.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk bde 95/04/07 16:13:44 Modified: lib/msun/src e_jn.c e_jnf.c Log: Submitted by: J.T. Conklin First part of update to fdlibm 5.2: fix jn(n, x) and jnf(n, x). jn(-1, x) was too large by a factor of 3. From owner-cvs-lib Fri Apr 7 16:23:36 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA23167 for cvs-lib-outgoing; Fri, 7 Apr 1995 16:23:36 -0700 Received: (from bde@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA23156 ; Fri, 7 Apr 1995 16:23:28 -0700 Date: Fri, 7 Apr 1995 16:23:28 -0700 From: Bruce Evans Message-Id: <199504072323.QAA23156@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/msun/src e_log10.c e_log10f.c e_rem_pio2.c e_rem_pio2f.c s_frexp.c s_frexpf.c Sender: cvs-lib-owner@freebsd.org Precedence: bulk bde 95/04/07 16:23:28 Modified: lib/msun/src e_log10.c e_log10f.c e_rem_pio2.c e_rem_pio2f.c s_frexp.c s_frexpf.c Log: Submitted by: J.T. Conklin Second part of update to fdlibm 5.2: speed up argument reduction for trig functions in the case pi/4 < |x| < 3pi/4. Remove unused static constants ("one"). From owner-cvs-lib Sat Apr 8 21:59:43 1995 Return-Path: cvs-lib-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01994 for cvs-lib-outgoing; Sat, 8 Apr 1995 21:59:43 -0700 Received: (from ache@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01984 ; Sat, 8 Apr 1995 21:59:41 -0700 Date: Sat, 8 Apr 1995 21:59:41 -0700 From: "Andrey A. Chernov" Message-Id: <199504090459.VAA01984@freefall.cdrom.com> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/gen setmode.3 Sender: cvs-lib-owner@freebsd.org Precedence: bulk ache 95/04/08 21:59:41 Modified: lib/libc/gen setmode.3 Log: Add missing header reference