Skip Navigational Links
LISTSERV email list manager
LISTSERV - COMMUNITY.EMAILOGY.COM
LISTSERV Menu
Log In
Log In
LISTSERV 17.5 Help - LSTSRV-L Archives
LISTSERV Archives
LISTSERV Archives
Search Archives
Search Archives
Register
Register
Log In
Log In

LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Menu
LISTSERV Archives LISTSERV Archives
LSTSRV-L Home LSTSRV-L Home

Log In Log In
Register Register

Subscribe or Unsubscribe Subscribe or Unsubscribe

Search Archives Search Archives
Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
Warning about VS PASCAL booleans
From:
Eric Thomas <[log in to unmask]>
Reply To:
LISTSERV give-and-take forum <[log in to unmask]>
Date:
Fri, 13 Aug 1993 18:26:01 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (22 lines)
I am posting this in case other people are writing non-PASCAL subroutines
called  from PASCAL  so you  don't waste  an hour  finding out  what your
problem was.
 
I don't know of any formal description of the machine format of VS PASCAL
booleans in  the manuals, other than  saying that they are  unaligned and
one  byte long.  Of course,  I  may just  have  missed it.  The code  the
compiler generates for IF instructions and the like checks for a value of
zero, anything else is TRUE. And of  course when you code IF NOT, it also
checks  for a  value of  zero and  just inverts  the branches.  It seemed
straightforward enough. But  it turns out that VS  PASCAL booleans really
have  three values:  FALSE  (zero), TRUE  (one), and  TRUE-NO-MATTER-WHAT
(anything else).  These booleans of the  third type work fine  as long as
you just  test them,  but once  you use  them in  an expression  which is
stored in a variable  or passed as a function argument, both  X and NOT X
turn out to be  true. This is because VS PASCAL does not  see fit to flip
the higher order bits, so the result  is nonzero no matter what. Your non
PASCAL subroutines had better return 1 and  not 255, or it will only work
most of the time.
 
  Eric

ATOM RSS1 RSS2

COMMUNITY.EMAILOGY.COM CataList Email List Search Powered by LISTSERV