Frozen Fish 2: PC/frozenfish_august_1995.bin/bbs/d03xx/d0353.lha/NorthC/NorthC2.LZH/bin/Bugs.doc

Text File | 1990-05-01 | 9KB | 348 lines

  (c) 1990 S.Hawtin.
  Permission is granted to copy this file and NorthC provided that:
   1) Neither are used for commercial gain
   2) This notice is included in all copies
   3) Altered copies are marked as such
   4) Each copy of NorthC is accompanied by a copy of this file.

  No liability is accepted for the contents of the file or the NorthC program.

  Bugs.doc      within        NorthC


  This file gives some hints about problems with "NorthC" programs, if
you find that a program you have compiled is behaving in a way you really
cannot explain and "libc.doc" is no help, you should read this file.

  This file is split into three sections, first the list of known bugs in
the current release, next a list of bugs fixed by this and previous releases
and finally a list of "hints".

  The known bugs are listed under the release that they were first noticed
in, the fixes are listed under the release that they were implemented in.

  The "hints" cover everything from bugs I have no immediate intention of
fixing to problems with the 'C' language that have caught me out in the
past.


Bugs
****

Version 1.1
***********

1.1.1  Standard C

  There are a number of features of ANSI 'C' that are not implemented in
NorthC.  NorthC is a fairly standard Kernigan & Ritchie first edition 'C'
that has been extended to move towards ANSI.

  The features that I know are missing are

    a)  locales
    b)  structure returns
    c)  function prototypes
    d)  #pragma #elif #val #error
    e)  The '#' and '##' operators
    f)  concatenating adjacent strings
    g)  multibyte characters
    h)  floats & doubles are too small
    i)  volatile and const storage classes


1.1.2  Assignments in if statements

  The assignment operator can be incorrectly optimised away in some
situations, for example the code

    if(x=7)
       {printf("foo");
        }

will notice that the assignment always returns a true value and so will
just call printf() without bothering to perform the assignment.  The
obvious fix is to convert the code to

    x=7;
    printf("foo");

to force the assignment.  If you typed the first code fragment I would
imagine that you meant

    if(x==7)
       {printf("foo");
        }

which is entirely different.


1.1.3  Library functions

  The library functions do not always act as expected, see "libc.doc" for
a complete description of the bugs and ommisions.

  The system() function always returns -1 regardless of the value
returned by the called program.

  scanf() does not support floating point numbers, see the note in the
Hints section.


1.1.4  Clearing address registers

  The compiler can produce incorrect assembler code, for example the
function

    foo()
       {register char *frob;
        frob = NULL;
        }

will cause the assembler to complain "Addressing mode not allowed here",
this can be fixed by making frob a stack based variable

    foo()
       {char *frob;
        frob = NULL;
        }

This is caused by the use of the "clr" instruction rather than moving
0L into the register.


1.1.5  Program name

  When a program is started up it should have its name in argv[0], however
NorthC always sets this string to "".  This will confuse some programs.


1.1.6  fseek()

  fseek() does not work correctly when seeking to the start of a "w+" file,
or at least when a switches from reading to writing.


Release 1.0
***********

1.0.1a  Declarations inside functions

  Declarations inside functions are dangerous, a definition such as

    example()
       {char *ex2();
        .
        .
        }

    char *
    ex2()
       {.
        .
        }

will fail to assemble because the predeclaration of ex2() will make the
assembler think it is an external function.  This gives undefined symbol
errors at link time.  This can be solved by placing the reference to ex2()
before the start of the example() function,

    char *ex2();

    example()
       {.
        .
        }

    char *
    ex2()
       {.
        .
        }

this is due to the fact that "A68K" requires all external references to be
defined.



Fixes
*****

  Here is a list of previously noted bugs that are now fixed.

Release 1.1
***********

1.0.1b  Declarations inside functions

  The bug that made static variables defined in functions crash the linker
has been fixed.  You can now write

    example()
       {static int jim;
        .
        .
        }

without crashing the linker or having the created program skip functions
on the return stack.


Hints
*****


  Large numbers of functions have not yet been implemeneted, or behave
differently from ANSI, see the "libc.doc" file for details.  If you find any
functions that you really need are not yet done you will have to write
them yourself.



  Integers are 16 bits, this causes problems in porting programs from some
compilers where integers and longs are the same size.  For example

    bar(jim)
        int jim;
       {.
        .
        }

    long foo;

    ex()
       {.
        .
        bar(foo+4);
        .
        .
        }

will not work, bar() will always take just the top 16 bits of the argument
it is passed.  Make sure you know if you are dealing with an integer or long.

  NOTE in the standard NorthC library all AmigaDOS functions require 32 bit
values, if you call them with "int"s they will get confused and probably
summon the guru.



  scanf() and all its relatives, behave in counter intuitive ways.  If you
use these functions you might have problems getting programs to work, and
you will certainly have problems porting your programs between machines, I
know for sure that there is a difference between NorthC scanf() and the one
in UNIX V.  I might not fix this problem, I have yet to find two versions
of 'C' that do the same thing with scanf(), I would recommend you just don't
use it.



  If the compiler suddenly starts crashing the machine whenever it is run
check how full the disk is.  If the OS returns a "disk full" error the
compiler may just carry on writing to the disk regardless.



  If your program dies with a message like "Error: 1004" this indicates a
library error, look in the ":include/errno.h" file to find out what the
library function is complaining about, or use the strerror() function.



  The compiler examines the value of the "INCLUDE" environment variable
and adds the listed directories to its include directories.  Separate
directories should have a ',' character between them.  For example to
look on the directories "df1:foo" "//jim" and "fred" issue the CLI command

    setenv INCLUDE "df1:foo,//jim,fred"

this feature has not been fully tested yet so it may be interesting to
use.



  Here is a clasic mistake that all real 'C' programmers must make at least
once, beware of the difference between

    if(jim==foo())
       {.
        .
        }

and

    if(jim=foo())
       {.
        .
        }

one of these is an assignment the other is a test, both are valid 'C'.
Some programmers guard against this by using

    #define EQ ==
    .
    .
    if(jim EQ foo())
       {.
        .
        }

of course you would put the first definition in an include file, "easyC.h"
for example.



  Large programs may cause Blink to have some problems, if you find that
some symbols refuse to link in very large programs try setting the
"SMALLCODE" flag.  If you keep finding that Blink is failing
to link symbols you know are defined try linking with the command

    cc -ooutname -bSMALLCODE foo.o bar.o baz.o

this fixes the problem for my largest program, NorthC.

  In general if the linker is causing problems it is worth setting it to
verbose, us a command such as

    cc -ooutname -bVERBOSE foo.o bar.o baz.o

this will at least give a clue as to where the linker problem was.



  There is no way at the moment to handle interrupts within NorthC, this
should be fixed when I find a book that explains what to do to handle them
in AmigaDOS.



  If you want to see how to write assembler that 'C' can call use the
"-s" option to "cc" to get hold of the intermediate assembler file then
edit that.  "cc" knows that .s files just need to be assembled.

  Look at "crt0.asm" to see how I have used the assembler, there may be
some good ideas to steal.

  When writing assembler be sure to restore the registers before you
return, NorthC expects you to alter the registers d0 d1 a0 and a1 but any
other registers must be restored or else very nasty things can happen.

  If you want to play with the low levels of the operating system I would
recommend that you use the debug() routine a lot.



  Here is another classic 'C' mistake,

    jim = 4;
    joe = jim<<2 + 3;

this will set joe to 128, not 19 as you might expect (well I would).  When
using the shift operator always put brackets to make the nesting obvious.



  Array indecies always start at 0 and go up to the number of elements minus
one.