raylau@dasys1.UUCP (Raymond Lau) (11/16/87)
Recently I've upgraded my version of LightspeedC to 2.13. By changing the
headers to the new ones that came with the upgrade, I had forgotten about
the many little changes I've put in.
I recompiled an application....and then ran it...wham, I am getting reports
of -36000k on my HD, etc.
The root of the problem was an obvious one. Things were declared as signed.
What I don't understand is why some things which make totally no sense
whatsoever if their content is negative...are declared as signed.
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!"...
-----------------------------------------------------------------------------
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."singer@endor.UUCP (11/17/87)
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) *