From owner-freebsd-arch@FreeBSD.ORG Wed Jun 28 12:55:30 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B82FF16A403 for ; Wed, 28 Jun 2006 12:55:30 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A27C43D58 for ; Wed, 28 Jun 2006 12:55:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id D46294D20C; Wed, 28 Jun 2006 22:55:25 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5SCtMaS010445; Wed, 28 Jun 2006 22:55:23 +1000 Date: Wed, 28 Jun 2006 22:55:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <75461.1151488426@critter.freebsd.dk> Message-ID: <20060628220742.V74922@delplex.bde.org> References: <75461.1151488426@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yar Tikhiy , arch@FreeBSD.org Subject: Re: SET, CLR, ISSET in types.h for _KERNEL builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 12:55:30 -0000 On Wed, 28 Jun 2006, Poul-Henning Kamp wrote: > In message <20060628094221.GA50978@comp.chem.msu.su>, Yar Tikhiy writes: >> On Tue, Jun 27, 2006 at 01:58:17PM -0600, M. Warner Losh wrote: > >>> NetBSD recently added SET, CLR, ISSET to sys/types.h (only if _KERNEL >>> is defined). I see no types here. > As one of the people who have worked with the original /bin/sh source > code, I have a slight alergic reaction to attempts to paste over > the implementation language with macros like these. > > Setting a bit in 'C' is spelled > variable |= bit; > not > SET(variable, bit); Only slightly? In FreeBSD, these mistakes were only in kern/tty.c and in some usb files obtained from NetBSD and related to tty.c. In tty.c, they appear to be just to avoid adding a USL copyright. (tty.c was obfuscated between FreeBSD-1 and FreeBSD-2 by globally substituting "variable |= BIT" by "SET(variable, BIT)", etc.) I noticed that NetBSD started using these macros elsewhere many years ago. However, their use was still relatively limited in NetBSD a year ago (in kern, they were only in kern-fork.c (1), kern_subr.c (2), kern_systrace.c (many), sys_process.c (a few), tty.c (many), tty_pty.c (many), vfs_bio.c (many) and vfs_lookup.c (1); 211 lines altogether vs 1565 lines matching ' & ' and 27 lines matching the style bug '[A-Za-z]&[A-Za-z]'). It must have been in tty_pty.c that I noticed them many years ago. > Higher order macros like roundup(), ispow2() are fine with me, > because they implement something on top of the language and make > the source code more compact and thus faster to read. > > But all of the three proposed macros take up more space than > the native language they obfuscate, what is the sense in that ? They might be to hide the implementation of a set of flags as a bitmap, but they don't even do that. Another problem with these macros is that a bitmap is more useful than a set of flags, but a much larger and uglier set of macros would be needed to give enough operations on bitmaps, and code that has been blindly translated from an integer-bitmap operation still assumes that the implementation is an integer-bitmap. E.g., in tty.c: %%% /* * delayed suspend (^Y) */ if (CCEQ(cc[VDSUSP], c) && ISSET(lflag, IEXTEN | ISIG) == (IEXTEN | ISIG)) { %%% Bruce