From owner-freebsd-arch Wed Sep 4 13: 5:19 2002 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 23AEA37B409 for ; Wed, 4 Sep 2002 13:05:08 -0700 (PDT) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52B5443E4A for ; Wed, 4 Sep 2002 13:05:07 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g84K4r8Z135342; Wed, 4 Sep 2002 16:04:53 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020905041751.F2483-100000@gamplex.bde.org> References: <20020905041751.F2483-100000@gamplex.bde.org> Date: Wed, 4 Sep 2002 16:04:51 -0400 To: Bruce Evans , Julian Elischer From: Garance A Drosihn Subject: Re: Process/thread states. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:30 AM +1000 9/5/02, Bruce Evans wrote: >On Wed, 4 Sep 2002, Julian Elischer wrote: > > > > The reason I consider using Macros to test and set these states is > > that several people suggested it as a way to abstract away the > > possible complications of the states. I'm kind of curious that > > almost no-one seems to have comments on this consider it's what > > I would consider to be prime arguing material. > > >> apparently no-one cares any more.. > >Macros are easier to write and maintain but harder to read and debug. >Especially the maintain and debug parts. Speaking for myself, in my own little tiny corner of the world (printing), one of the biggest problems I have with LPRng is that it has so many macros for everything. You effectively end up with a specialized language which is using cpp as the "compiler", instead of reading plain C code. Every time you're reading along, you have to stop and go back to see "what is this macro REALLY doing?". That's just me, of course -- ymmv. Chances are that I will never ever be debugging the kernel-level code that you're working on, so in that sense I don't want to annoy you with a debate over what you're doing (aka "I don't care"). And obviously I am happy to define the occasional macro when I'm writing code for lpr, but in general I find it frustrating when I'm debugging any code which resorts to macros for too many things. It is particularly bad if the code *sometimes* uses macros to fiddle with a given value, and other times it will operate directly on the value. Thus, the problem isn't that the macro itself is wrong, but that the macro hides a bug which is caused by some *other* code around the macro, which is manipulating the same variables but has no obviously-visible connection to the macro. This is just a matter of me rambling though. At the moment I'm fighting a samba server (running on linux...) which has suddenly decided to crash every six hours (now that our semester has started up), and this topic is a welcome diversion from that extreme irritation... Cheerio. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message