home *** CD-ROM | disk | FTP | other *** search
- Path: wossname.apana.org.au!fjc
- Subject: Re: BUG IN "STATUS" COMMAND FOUND
- Newsgroups: comp.sys.amiga.programmer
- References: <4f403j$qpm@jeack.apana.org.au>
- Distribution: world
- X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
- From: fjc@wossname.apana.org.au (Frank Copeland)
- Message-ID: <fjc.2plc@wossname.apana.org.au>
- Date: Mon, 5 Feb 96 14:51:35 +1000
- Organization: International Oberon Secret Society
-
- Brett Eden (brett@jeack.apana.org.au) wrote:
- : I have located a bug in the status command, under workbench 3, and it goes
- : like this:
-
- It happens under KS 2.05 + WB 2.1 too.
-
- Just a bit of background first:
-
- Every CLI task (off-hand I'm not certain what qualifies a task to be a CLI
- task, but running it from a CLI would be favourite) has a unique
- identifier, stored in the pr_TaskNum field of its Process structure. This
- is an index into a table of ProcessId's which is stored in dos.library's
- base structure. This field is defined as a LONG, which is a *signed* 32-bit
- integer. It's maximum value is therefore 2^31-1, which just happens to be
- 2147483647. The minimum legal value for a CLI is 1 (0 is reserved to
- indicate a non-CLI process), but a signed integer can have a minimum value
- of -2^31, or -2147483648. Remember these numbers.
-
- : 7. System:> Status 2147483647
- :
- : Causes the shell from which the command was initiated, to freeze, until a ^C
- : is issued.
-
- This *should* be a legal CLI number, in fact the highest possible CLI
- number. Perhaps it is a 'magic' number and has some undocumented
- significance to the system which throws the STATUS command into a fit.
- Congratulations, you've found a bug :-).
-
- : 7. System:> Status 2147483648
- :
- : Returns an error "Process -2147483648 does not exist" - which, obviously,
- : is true, but where did it get the negative sign from?
-
- Remember that the CLI number is a *signed* integer. 2147483648 is 2^31,
- which is beyond the range of signed integers. However, its valid as an
- *unsigned* integer and the bit pattern for unsigned 2147483648 is the same
- as for signed -2147483648. What I suspect is happening here is that the
- ReadArgs() function (which is a dos.library function used to parse command
- lines) is reading the argument as an unsigned integer then converting it to
- a signed integer. Actually, its more likely to be simply re-interpreting
- the bit pattern as signed.
-
- : 7. System:> Status 2147483649
- :
- : Returns an error "Process -2147483647 does not exist" - which again is true,
- : but -2147483647 wasn't the number I entered, was it?
-
- Same as above.
-
- : 7. System:> Status 2147483650
- :
- : Returns an error "Bad number" which indicates to us that 2147483649 is
- : the ceiling value.
-
- Now *this* is somewhat weird. Why call this a bad number and not the
- previous two which are also out of range for signed integers? If my theory
- is correct, and ReadArgs() is reading numeric arguments as unsigned before
- converting them to signed, then this suggests that whoever wrote ReadArgs()
- has used the wrong value for the maximum value of a signed integer.
-
- : I know this bug plays no trouble in the workings of the system, but it's
- : a bug nonetheless, and will give Escom/AmiTech something to do =)
-
- If you had 1000 bug reports, and had to allocate a priority level to each
- one, what priority would you give this one? Put it another way: don't
- expect to see this bug fixed any time soon, if ever :-).
-
- Frank Copeland
- --
- MODULE Sig;
- (* $Author: Frank Copeland <fjc@wossname.apana.org.au> $ *)
- IMPORT StdDisclaimer, CleverQuote, AdvocateOberon;
- END Sig.
-