From owner-freebsd-bugs@FreeBSD.ORG Wed Aug 2 07:30:14 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BBF916A4DF for ; Wed, 2 Aug 2006 07:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D785F43D4C for ; Wed, 2 Aug 2006 07:30:12 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k727UCel019022 for ; Wed, 2 Aug 2006 07:30:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k727UCh4019021; Wed, 2 Aug 2006 07:30:12 GMT (envelope-from gnats) Resent-Date: Wed, 2 Aug 2006 07:30:12 GMT Resent-Message-Id: <200608020730.k727UCh4019021@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Darren Pilgrim Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC69916A4DD for ; Wed, 2 Aug 2006 07:25:24 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ECB643D5A for ; Wed, 2 Aug 2006 07:25:23 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k727PMMc030782 for ; Wed, 2 Aug 2006 07:25:22 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k727PMgW030771; Wed, 2 Aug 2006 07:25:22 GMT (envelope-from nobody) Message-Id: <200608020725.k727PMgW030771@www.freebsd.org> Date: Wed, 2 Aug 2006 07:25:22 GMT From: Darren Pilgrim To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: misc/101245: Typo-fixing session on the src tree X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 07:30:14 -0000 >Number: 101245 >Category: misc >Synopsis: Typo-fixing session on the src tree >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Aug 02 07:30:12 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Darren Pilgrim >Release: HEAD >Organization: none >Environment: n/a >Description: After mentioning a typo on cvs-all, Yar Tikhiy suggested in private mail that I do a larger typo-fixing run. Specifically, correct "lose" vs. "loose" usage. This diff is the product of that typo-fixing session. The search was against a copy of -CURRENT downloaded 2006/08/02 01:51 UTC. My search ignored src/contrib/*, src/crypto/open* and src/sys/contrib/*. The diff provided includes comments with partial file IDs. >How-To-Repeat: Hopefully repetition can be avoided. :) >Fix: # src/bin/sh/histedit.c,v 1.28 2005/10/19 15:37:42 --- src/bin/sh/histedit.c.orig Wed Oct 19 08:37:42 2005 +++ src/bin/sh/histedit.c Tue Aug 1 19:55:08 2006 @@ -370,7 +370,7 @@ fputs(s, efp); } /* - * At end? (if we were to loose last, we'd sure be + * At end? (if we were to lose last, we'd sure be * messed up). */ if (he.num == last) # src/games/fortune/datfiles/fortunes,v 1.223 2006/07/10 16:53:32 --- src/games/fortune/datfiles/fortunes.orig Mon Jul 10 09:53:32 2006 +++ src/games/fortune/datfiles/fortunes Tue Aug 1 22:53:15 2006 @@ -5459,7 +5459,7 @@ Most of us just sit back and marvel at such a story; how could that terminal know whether the poor guy was sitting or standing? Good debuggers, though, know that there has to be a reason. Electrical theories are the easiest to -hypothesize: was there a loose with under the carpet, or problems with static +hypothesize: was there a loose wire under the carpet, or problems with static electricity? But electrical problems are rarely consistently reproducible. An alert IBMer finally noticed that the problem was in the terminal's keyboard: the tops of two keys were switched. When the programmer was seated he was a # src/lib/libc/sys/kse.2,v 1.17 2005/11/24 07:33:35 --- src/lib/libc/sys/kse.2.orig Wed Nov 23 23:33:35 2005 +++ sr/lib/libc/sys/kse.2 Tue Aug 1 22:45:07 2006 @@ -267,7 +267,7 @@ .Pp As a special case, if the last remaining KSE in the last remaining KSE group invokes this system call, then the KSE is not destroyed; -instead, the KSE just looses the association with its mailbox and +instead, the KSE just loses the association with its mailbox and .Fn kse_exit returns normally. This returns the process to its original, unthreaded state. # src/release/doc/fr_FR.ISO8859-1/hardware/alpha/proc-alpha.sgml,v 1.5 2002/12/30 21:18:04 --- src/release/doc/fr_FR.ISO8859-1/hardware/alpha/proc-alpha.sgml.orig Mon Dec 30 13:18:04 2002 +++ src/release/doc/fr_FR.ISO8859-1/hardware/alpha/proc-alpha.sgml Tue Aug 1 22:47:14 2006 @@ -1212,7 +1212,7 @@ IDE interface is quite slow, a Promise card gives a 3-4 times speed improvement. - On PC164 the SRM sometimes seems to loose its variable settings. + On PC164 the SRM sometimes seems to lose its variable settings. For PC164, current superstition says that, to avoid losing settings, you want to first downgrade to SRM 4.x and then upgrade to 5.x. One sample error that was observed was: # src/share/doc/papers/timecounter/timecounter.ms,v 1.3 2004/02/23 23:39:42 --- src/share/doc/papers/timecounter/timecounter.ms.orig Mon Feb 23 15:39:42 2004 +++ src/share/doc/papers/timecounter/timecounter.ms Tue Aug 1 22:47:43 2006 @@ -72,7 +72,7 @@ ?) about which we know the least, it is at the same time [sic!] what we can measure with the highest precision of all physical quantities. .LP -The current crop of atomic clocks will neither gain nor loose a +The current crop of atomic clocks will neither gain nor lose a second in the next couple hundred million years, provided we stick to the preventative maintenance schedules. This is a feat roughly in line with to knowing the circumference of the Earth # src/share/man/man4/devctl.4,v 1.4 2005/12/30 14:01:01 --- src/share/man/man4/devctl.4.orig Fri Dec 30 06:01:01 2005 +++ src/share/man/man4/devctl.4 Tue Aug 1 22:48:25 2006 @@ -69,7 +69,7 @@ The read channel for this device is used to report changes to userland in realtime. We return one record at a time. -If you try to read this device a character at a time, you will loose +If you try to read this device a character at a time, you will lose the rest of the data. Listening programs are expected to cope. .Pp # src/sys/boot/i386/loader/main.c,v 1.36 2005/12/21 02:17:58 --- src/sys/boot/i386/loader/main.c.orig Tue Dec 20 18:17:58 2005 +++ src/sys/boot/i386/loader/main.c Tue Aug 1 22:49:29 2006 @@ -226,7 +226,7 @@ /* * If we are booted by an old bootstrap, we have to guess at the BIOS - * unit number. We will loose if there is more than one disk type + * unit number. We will lose if there is more than one disk type * and we are not booting from the lowest-numbered disk type * (ie. SCSI when IDE also exists). */ # src/sys/boot/pc98/loader/main.c,v 1.22 2005/12/21 06:10:42 --- src/sys/boot/pc98/loader/main.c.orig Tue Dec 20 22:10:42 2005 +++ src/sys/boot/pc98/loader/main.c Tue Aug 1 22:49:44 2006 @@ -218,7 +218,7 @@ /* * If we are booted by an old bootstrap, we have to guess at the BIOS - * unit number. We will loose if there is more than one disk type + * unit number. We will lose if there is more than one disk type * and we are not booting from the lowest-numbered disk type * (ie. SCSI when IDE also exists). */ # src/sys/dev/bktr/CHANGELOG.TXT,v 1.21 2006/07/01 10:51:54 --- src/sys/dev/bktr/CHANGELOG.TXT.orig Sat Jul 1 03:51:54 2006 +++ src/sys/dev/bktr/CHANGELOG.TXT Tue Aug 1 23:01:33 2006 @@ -182,7 +182,7 @@ video_open() function select PAL rather than NTSC. This fixed all the hangs on my Dual Crystal card when using a PAL video signal. As a result, you - can loose the tsleep (of 2 seconds - now 0.25!!) + can lose the tsleep (of 2 seconds - now 0.25!!) which I previously added. (Unless someone else wanted the 0.25 second tsleep). # src/sys/dev/dpt/dpt_scsi.c,v 1.51 2006/05/16 14:36:24 --- src/sys/dev/dpt/dpt_scsi.c.orig Tue May 16 07:36:24 2006 +++ src/sys/dev/dpt/dpt_scsi.c Tue Aug 1 23:02:02 2006 @@ -1811,7 +1811,7 @@ s = splcam(); /* - * Try to clear any pending jobs. FreeBSD will loose interrupts, + * Try to clear any pending jobs. FreeBSD will lose interrupts, * leaving the controller suspended, and commands timed-out. * By calling the interrupt handler, any command thus stuck will be * completed. # src/sys/dev/em/if_em.c,v 1.122 2006/07/27 00:43:34 --- src/sys/dev/em/if_em.c.orig Wed Jul 26 17:43:34 2006 +++ src/sys/dev/em/if_em.c Tue Aug 1 23:02:20 2006 @@ -1033,7 +1033,7 @@ } em_initialize_receive_unit(sc); - /* Don't loose promiscuous settings */ + /* Don't lose promiscuous settings */ em_set_promisc(sc); ifp->if_drv_flags |= IFF_DRV_RUNNING; # src/sys/dev/fe/if_fe.c,v 1.96 2005/11/11 16:04:51 --- src/sys/dev/fe/if_fe.c.orig Fri Nov 11 08:04:51 2005 +++ src/sys/dev/fe/if_fe.c Tue Aug 1 23:02:58 2006 @@ -1197,7 +1197,7 @@ * If txb_count is incorrect, leaving it as-is will cause * sending of garbage after next interrupt. We have to * avoid it. Hence, we reset the txb_count here. If - * txb_free was incorrect, resetting txb_count just loose + * txb_free was incorrect, resetting txb_count just loses * some packets. We can live with it. */ sc->txb_count = 0; # src/sys/dev/ixgb/if_ixgb.c,v 1.18 2005/12/18 18:24:26 --- src/sys/dev/ixgb/if_ixgb.c.orig Sun Dec 18 10:24:26 2005 +++ src/sys/dev/ixgb/if_ixgb.c Tue Aug 1 23:03:22 2006 @@ -697,7 +697,7 @@ } ixgb_initialize_receive_unit(adapter); - /* Don't loose promiscuous settings */ + /* Don't lose promiscuous settings */ ixgb_set_promisc(adapter); ifp = adapter->ifp; # src/sys/dev/patm/if_patm_intr.c,v 1.6 2005/08/09 10:19:51 --- src/sys/dev/patm/if_patm_intr.c.orig Tue Aug 9 03:19:51 2005 +++ src/sys/dev/patm/if_patm_intr.c Tue Aug 1 23:03:52 2006 @@ -226,7 +226,7 @@ * Feeding buffers is actually not so easy as it seems. We cannot use the * fraction fields in the status registers, because they round down, i.e. * if we have 34 buffers in the queue, it will show 1. If we now feed - * 512 - 1 * 32 buffers, we loose two buffers. The only reliable way to know + * 512 - 1 * 32 buffers, we lose two buffers. The only reliable way to know * how many buffers are in the queue are the FBQP registers. */ static u_int # src/sys/dev/pci/pcivar.h,v 1.69 2006/01/01 20:40:08 --- src/sys/dev/pci/pcivar.h.orig Sun Jan 1 12:40:08 2006 +++ src/sys/dev/pci/pcivar.h Tue Aug 1 23:04:32 2006 @@ -317,10 +317,10 @@ * power from the system and delivering full functionality to the user. * D1 Class-specific low-power state in which device context may or may not * be lost. Buses in D1 cannot do anything to the bus that would force - * devices on that bus to loose context. + * devices on that bus to lose context. * D2 Class-specific low-power state in which device context may or may * not be lost. Attains greater power savings than D1. Buses in D2 - * can cause devices on that bus to loose some context. Devices in D2 + * can cause devices on that bus to lose some context. Devices in D2 * must be prepared for the bus to be in D2 or higher. * D3 State in which the device is off and not running. Device context is * lost. Power can be removed from the device. # src/sys/dev/sym/sym_fw1.h,v 1.7 2005/01/06 01:43:24 --- src/sys/dev/sym/sym_fw1.h.orig Wed Jan 5 17:43:24 2005 +++ src/sys/dev/sym/sym_fw1.h Tue Aug 1 23:05:11 2006 @@ -317,7 +317,7 @@ /* * Now there are 4 possibilities: * - * (1) The chip looses arbitration. + * (1) The chip loses arbitration. * This is ok, because it will try again, * when the bus becomes idle. * (But beware of the timeout function!) # src/sys/dev/sym/sym_fw2.h,v 1.8 2005/01/06 01:43:24 --- src/sys/dev/sym/sym_fw2.h.orig Wed Jan 5 17:43:24 2005 +++ src/sys/dev/sym/sym_fw2.h Tue Aug 1 23:05:20 2006 @@ -290,7 +290,7 @@ /* * Now there are 4 possibilities: * - * (1) The chip looses arbitration. + * (1) The chip loses arbitration. * This is ok, because it will try again, * when the bus becomes idle. * (But beware of the timeout function!) # src/sys/fs/hpfs/hpfs.h,v 1.19 2005/03/16 07:21:38 --- src/sys/fs/hpfs/hpfs.h.orig Tue Mar 15 23:21:38 2005 +++ src/sys/fs/hpfs/hpfs.h Tue Aug 1 23:05:51 2006 @@ -311,7 +311,7 @@ struct sublock hpm_su; struct spblock hpm_sp; struct mount * hpm_mp; - struct vnode * hpm_devvp; /* XXX: loose this, it's in hpfsmount */ + struct vnode * hpm_devvp; /* XXX: lose this, it's in hpfsmount */ struct g_consumer *hpm_cp; struct bufobj *hpm_bo; struct cdev *hpm_dev; # src/sys/geom/bde/g_bde_work.c,v 1.27 2005/10/31 15:41:22 --- src/sys/geom/bde/g_bde_work.c.orig Mon Oct 31 07:41:22 2005 +++ src/sys/geom/bde/g_bde_work.c Tue Aug 1 23:06:22 2006 @@ -646,7 +646,7 @@ PRIBIO, "-", hz); if (error == EWOULDBLOCK) { /* - * Loose our skey cache in an orderly fashion. + * Lose our skey cache in an orderly fashion. * The exact rate can be tuned to be less * aggressive if this is desirable. 10% per * second means that the cache is gone in a # src/sys/geom/mirror/g_mirror.c,v 1.86 2006/08/01 23:17:33 --- src/sys/geom/mirror/g_mirror.c.orig Tue Aug 1 16:17:33 2006 +++ src/sys/geom/mirror/g_mirror.c Tue Aug 1 23:22:37 2006 @@ -2079,7 +2079,7 @@ * and more fresh disk just arrive. * If there were writes, mirror is broken, sorry. * I think the best choice here is don't touch - * this disk and inform the user laudly. + * this disk and inform the user loudly. */ G_MIRROR_DEBUG(0, "Device %s was started before the freshest " "disk (%s) arrives!! It will not be connected to the " # src/sys/geom/raid3/g_raid3.c,v 1.70 2006/08/01 23:17:33 --- src/sys/geom/raid3/g_raid3.c.orig Tue Aug 1 16:17:33 2006 +++ src/sys/geom/raid3/g_raid3.c Tue Aug 1 23:22:45 2006 @@ -2353,7 +2353,7 @@ * and more fresh disk just arrive. * If there were writes, device is broken, sorry. * I think the best choice here is don't touch - * this disk and inform the user laudly. + * this disk and inform the user loudly. */ G_RAID3_DEBUG(0, "Device %s was started before the freshest " "disk (%s) arrives!! It will not be connected to the " # src/sys/i386/i386/tsc.c,v 1.205 2006/02/11 09:33:06 --- src/sys/i386/i386/tsc.c.orig Sat Feb 11 01:33:06 2006 +++ src/sys/i386/i386/tsc.c Tue Aug 1 23:07:24 2006 @@ -94,11 +94,11 @@ init_TSC_tc(void) { /* - * We can not use the TSC if we support APM. Precise timekeeping + * We can not use the TSC if we support APM. Precise timekeeping * on an APM'ed machine is at best a fools pursuit, since * any and all of the time spent in various SMM code can't * be reliably accounted for. Reading the RTC is your only - * source of reliable time info. The i8254 looses too of course + * source of reliable time info. The i8254 loses too, of course, * but we need to have some kind of time... * We don't know at this point whether APM is going to be used * or not, nor when it might be activated. Play it safe. # src/sys/kern/kern_resource.c,v 1.158 2006/03/11 10:48:19 --- src/sys/kern/kern_resource.c.orig Sat Mar 11 02:48:19 2006 +++ src/sys/kern/kern_resource.c Tue Aug 1 23:07:54 2006 @@ -1087,7 +1087,7 @@ * that we don't need to free, simply unlock and return. * Suboptimal case: * If refcount lowering results in need to free, bump the count - * back up, loose the lock and aquire the locks in the proper + * back up, lose the lock and aquire the locks in the proper * order to try again. */ void # src/sys/kern/kern_tc.c,v 1.176 2006/06/16 20:29:05 --- src/sys/kern/kern_tc.c.orig Fri Jun 16 13:29:05 2006 +++ src/sys/kern/kern_tc.c Tue Aug 1 23:08:14 2006 @@ -961,7 +961,7 @@ * years) and in 64 bits at 4 GHz (146 years), but if we do a multiply * before divide conversion (to retain precision) we find that the * margin shrinks to 1.5 hours (one millionth of 146y). - * With a three prong approach we never loose significant bits, no + * With a three prong approach we never lose significant bits, no * matter what the cputick rate and length of timeinterval is. */ # src/sys/kern/subr_bus.c,v 1.194 2006/07/08 17:06:14 --- src/sys/kern/subr_bus.c.orig Sat Jul 8 10:06:14 2006 +++ src/sys/kern/subr_bus.c Tue Aug 1 23:08:35 2006 @@ -417,7 +417,7 @@ * userland in realtime. We are required to free the data as well as * the n1 object because we allocate them separately. Also note that * we return one record at a time. If you try to read this device a - * character at a time, you will loose the rest of the data. Listening + * character at a time, you will lose the rest of the data. Listening * programs are expected to cope. */ static int # src/sys/pci/ncr.c,v 1.189 2006/05/12 05:04:45 --- src/sys/pci/ncr.c.orig Thu May 11 22:04:45 2006 +++ src/sys/pci/ncr.c Tue Aug 1 23:10:28 2006 @@ -1532,7 +1532,7 @@ /* ** Now there are 4 possibilities: ** - ** (1) The ncr looses arbitration. + ** (1) The ncr loses arbitration. ** This is ok, because it will try again, ** when the bus becomes idle. ** (But beware of the timeout function!) >Release-Note: >Audit-Trail: >Unformatted: