Fish 'n' More 2/fishmore-publicdomainlibraryvol.ii1991xetec.iso/fish/languages/northc_384/bin/bugs.doc

Text File | 1990-09-08 | 9KB | 291 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.2
 ***********

1.2.6  unsigned short Function Arguments

  Because all integers are now four bytes there seems to be a problem with
functions that have unsigned short arguments.  The calling function expands
these two byte values into four bytes but the called function assumes they
are two bytes long, and wowee we have messed the stack up.

1.2.7  "%hd" qualifier in printf

  The short qualifier "h" does not work in printf.

 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 #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 and of course works.

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 omissions.

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

  scanf() does not fully support floating point numbers, see the note in
the Hints section.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,
for example the UNIX "uncompress" and "compress" programs rely on knowing
the name they were called with.

1.1.6  fseek()

  There are some occasions when fseek() functions incorrectly, as yet I
have no consistent example of this bug.

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

  All the bugs reported in release 1.0 have been fixed.

 Fixes
 *****

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

 Release 1.2
 ***********

1.2.1  strtol()

1.1.4  Clearing address registers

1.0.1a  Declarations inside functions

1.2.2  #undef (from M.Combs)

1.2.4  Initialised static arrays in functions

1.2.5  fgetc() return value.

1.2.3  open() in the UNIX library

1.2.8  Initialising unsigned char arrays (from M.Combs)

1.2.9  ctime() and asctime() (from M.Combs)

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

1.0.1b  Declarations inside functions

 Hints
 *****

  Large numbers of functions have not yet been implemented, 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.

  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.  However the version of scanf() under UNIX doesn't work
either.  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 classic 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 play with assembler then just call "NorthC" on your ".c"
file, this will produce a ".s" file that you can examine.  The "make"
program knows how to create object files from ".s" files.

  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 indices always start at 0 and go up to the number of elements
minus one.  This can have some interesting effect, for example the function

    foo()
       {
        int i;
        int array[4];

        for(i=0;i<=4;i++)
            array[i] = 0;
        .
        .
        }

could be an infinite loop, because when the function sets array[4] to zero
it actually sets i to zero.

  Always use the system include files to define the library functions, for
example if you write some code

    foo()
       {extern long atol();
        .
        .
        jim = atol(str);
        }

then NorthC will give an error message, this is because atol() is defined
as a macro in NorthC.  The correct way to access the function is

    #include <stdlib.h>

    foo()
       {
        jim = atol(str);
        }

this will obtain the correct definition from the "stddef.h" file.