home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!noc.near.net!ds5000!cschmidt
- From: cschmidt@ds5000.DAC.Northeastern.edu (Christopher Schmidt)
- Newsgroups: comp.lang.pascal
- Subject: LENGTH and POS in TP 5.5
- Message-ID: <7351@ds5000.DAC.Northeastern.edu>
- Date: 4 Sep 92 04:22:23 GMT
- Organization: Northeastern University, Boston MA. USA 02115
- Lines: 62
-
- Here is a problem with the LENGTH function in TP 5.5 that cost me
- several hours of debugging. After discovering the source of the
- problem, I investigated the POS function as well.
-
- The TP 5.5 documentation says the LENGTH function returns a value
- of type integer. Apparently, it actually returns a value of type
- byte. If the return value were of type integer, then the
- following program would display the numbers 256 and -1. Instead,
- the program displays the values 0 and 255.
-
- var
- s : string;
- begin
- s [0] := #255;
- writeln (succ (length (s)));
-
- s [0] := #0;
- writeln (pred (length (s)));
- end.
-
- The following two workarounds produce exactly identical code.
-
- Workaround 1: Typecast the result of LENGTH to integer.
-
- succ (integer (length (s)))
- pred (integer (length (s)))
-
- Workaround 2: Use +1 and -1 instead of SUCC and PRED.
-
- length (s) + 1
- length (s) - 1
-
- The TP 5.5 documentation says the POS function returns a value of
- type byte. Apparently, it actually returns a value of type
- integer. If the return value were of type byte, then the
- following program would display the numbers 0 and 256. Instead,
- the program displays the values 256 and -1.
-
- var
- s : string;
- begin
- fillchar (s, sizeof (s), 255);
-
- s [255] := 'A';
- writeln (succ (pos ('A', s)));
-
- s [255] := ' ';
- writeln (pred (pos ('A', s)));
- end.
-
- This program compiles to exactly the same code as when the POS
- function is typecast to integer, or when +1 and -1 are used
- instead of SUCC and PRED.
-
- NOTE TO BORLAND: When you fix these and other problems, please
- let use know, so we can determine whether your fix invalidates
- our workarounds. Thank you.
-
- Christopher Schmidt
- Waltham, Massachusetts, USA
- cschmidt@lynx.northeastern.edu
-
-