Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!hao!husc6!endor!singer From: singer@endor.UUCP Newsgroups: comp.sys.mac Subject: Re: unsigned vs. signed Message-ID: <3227@husc6.UUCP> Date: Tue, 17-Nov-87 08:45:39 EST Article-I.D.: husc6.3227 Posted: Tue Nov 17 08:45:39 1987 Date-Received: Thu, 19-Nov-87 06:18:16 EST References: <1986@dasys1.UUCP> Sender: news@husc6.UUCP Reply-To: singer@endor.UUCP (Richard Siegel) Organization: THINK Technologies, Inc., Bedford, MA Lines: 40 Keywords: Why use signed when it is meaningless? In article <1986@dasys1.UUCP> raylau@dasys1.UUCP (Raymond Lau) writes: > >In this particular case, why is the ioFrBlks (or whatever) of the volumeParam >field declared as a signed integer? I cannot see how a volume can have a >negative number of free blocks. Although it hasn't happened yet, bec. I >don't deal with drives of large allocation block sizes nor large files yet, >a similar problem can occur with the ioVAlBlkSiz field and the size fields >of the fileParam. There are many other instances which can cause a similar >problem. > >The only justification for this, which I think is silly, is that these fields >are declared as signed in Inside Mac. I don't know why though... but it's >silly for one to "correct" these declarations each time there is an update >out. "So use your old headers!" - that's like saying...."So write your >own compiler!"... > "silly" is a distinction that I'm not going to argue about; since in this context it's purely a matter of convenience. When we set up the headers for the ROM interfaces, we attempted to conform completely to the definitions in Inside Macintosh. We didn't question their usage of signed integers vs. unsigned integers. Also, remember that the ROM interfaces are in Pascal, and in Pascal, there is no such thing as an "Unsigned" data type. >----------------------------------------------------------------------------- >Raymond Lau {allegra,philabs,cmcl2}!phri\ >Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!raylau >New York, NY, USA {sun}!hoptoad/ >GEnie:RayLau Delphi:RaymondLau CIS:76174,2617 >"Take it and StuffIt." --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *