ORCA/C 2.0 bugs

[dempson@swell.actrix.gen.nz (David Empson)]

ORCA/C 2.0 arrived a couple of days ago, and I've just installed it.
I went through my 'known bugs' list to see if there were any problems,
and tried a few other small test programs.  I came up with the
following bugs.

Which (if any) of these bugs have already been reported to Byte Works?
Once I have a better idea of the cause of these, I'll be sending a
letter to Mike.

Does anyone have any more bugs that they can tell me about?  (E-Mail, if
you don't want to repeat yourself in public, and I can post a summary.)

System details: ROM 03 IIgs, System 6.0, 60 MB hard drive (Apple HS
SCSI), 5 MB of RAM (800k /RAM5), no accelerator.  ORCA/Shell 2.0.1,
ORCA/C 2.0.0, using the text environment with EdIt-16 1.0.

1.   [Library] If gets() is used and a blank line is entered, nothing
     is written into the target string (a null terminator should be
     written into the first byte).  I haven't tried fgets().  [Bug
     also in 1.3]

2.   [Library] The FWEntry glue code passes the parameters in the
     wrong order to the toolbox call, resulting in a crash.  [Bug also
     in 1.3]

3.   Compiler doesn't catch an error in the following.  I accidentally
     used the same name for a global function and local variable, and
     tried to call the function:

     char *filesys(word);

     void show_filesys(word fs) {
          char *filesys;
          printf("(%s)", filesys(fs));
     }

     The compiler generates code which calls the character pointer!

     In version 1.3, the compiler hung when trying to compile the
     show_filesys function.

4.   The parameter structure for the WriteTimeHex call has its fields
     in the wrong order.  In version 1.3, misctool.h claimed that
     WriteTimeHex was a library routine, but no glue code was provided
     to call the toolbox, resulting in a linker error.

5.   [Shell or Library] Strange problems with standard input.

(a)  Programs compiled with ORCA/C 1.3 work fine in Shell 2.0.0.
(b)  Programs compiled with ORCA/C 2.0.0 ignore input redirection in
     Shell 2.0.0.  See also item 6.
(c)  Programs compiled with ORCA/C 1.3 or 2.0.0 hang with Shell 2.0.1
     if input redirection is used.  The computer appears to be stuck
     in a loop inside GS/OS.

6.   [Shell or Library] Bug in handling input from .CONSOLE (Shell
     2.0.0 and 2.0.1).
     If output redirection is used with a simple "copy standard in to
     standard out" program, some CR characters are sent to the wrong
     destination.
     When the .CONSOLE formatted read routine is used, the program
     must output a CR to bring the cursor down to the next line.  The
     CR is being sent to the current output device or file, not to
     .CONSOLE.  This means that extra CRs are written to the output
     file, and the input lines are tacked on the end of each other.
     This doesn't happen if the program is compiled with ORCA/C 1.3.

7.   [Shell 2.0.1 or ORCA/C 2.0.0] Either of these is causing frequent
     crashes - I have to reboot after a few compiles.  No problem when
     going back to Shell 2.0.0 and ORCA/C 1.3.  Symptom is random
     memory location getting set to zero, usually in GS/OS or a
     previously loaded program (such as the Linker).

8.   [Compiler] Serious bug in automatic type conversions.  
     If an unsigned integer VARIABLE is added to a long, the compiler
     generates code to sign extend the unsigned integer.  It should be
     setting the high word to zero, not the sign extension of the low
     word.  Here is an example:

     unsigned int u = 32768U;
     printf("65536 + 32768 = %lu\n", 65536L + u);

     The program should print 98304, but it prints 32768!
     The program works correctly if an unsigned constant is used.  I
     haven't tried more complex expressions than a constant or a
     single variable.

Due to the serious nature of the last two problems, I don't feel
comfortable using ORCA/C 2.0 yet, so I'll be continuing to use 1.3
until the next release.

The following are bugs that I found in ORCA/C 1.3, which have been
fixed in 2.0:

1.   [Library] fscanf(), scanf() and sscanf() hung if end of input was
     reached while skipping whitespace.

2.   isspace(var) where var contains -1 (and the other classification
     macros).  ORCA/C 1.3 indexed 65535 bytes past the array and
     returned a random result.  The same applied to any expression of
     the form *(pointer + var), pointer[var] or array[var], where var
     contained a negative value.

3.   In the small memory model, adding an integer constant to a
     pointer didn't update the high word of the pointer.  This
     prevented any data structure crossing a 64k boundary (including
     anything that the toolbox returned to the program, such as a
     block from NewHandle, or a resource).

4.   Compiler hung when compiling the following (erroneous)
     expression:

          b = ((*(__ctype+1)(a) & __space));

     ORCA/C 2.0 reports several errors (including "Compiler bug").

5.   Wrong code generated for the following (osrc and odest are
     OpenRecGS structures).

          osrc.resourceNumber = odest.resourceNumber += 1;

     (i.e. increment resource number for destination file and copy it
     to the source file parameter block).
     The compiler didn't push the address of the first variable, then
     tried to pull it off the stack later, causing stack corruption.

6.   Hex and octal constants from 0x8000 to 0xFFFF were treated as
     signed long, rather than unsigned int.

7.   [Library] gmtime() and localtime() returned the wrong date if the
     time was exactly midnight on the first of a month.
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz    <--- Note my new E-Mail address!            
Snail mail: P.O. Box 27-103, Wellington, New Zealand