[net.micro.atari16] shar

rwb@druxu.UUCP (BlackR) (10/25/86)

Upon reading the code for the shar/unshar program recently posted to the
net, I noticed the warnings about the Lattice C libraries.  Since Lattice
has released version 3.03.04 (the comments apply to version 3.03.02), I
felt I had better post a copy of a letter I sent to Lattice regarding
problems in the newer library.  The 20 file problem has been fixed, but
some other problems have been introduced that will affect compiling shar.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                                        Sept. 13, 1986
METACOMCO
5353E Scotts Valley Drive
Scotts Valley, CA 95066

Dear Sirs:

I  have your Lattice C compiler, version 3.03.04, serial number
xxxx  for  the Atari 520ST and have some comments on the product.
First, the bugs.  

Try running the following program (enclosed is the output).  

/*This program tests a bug in the Lattice compiler, version 3.03.04*/
#define SIZE 12
main()
{
        char db[SIZE], *tmp;
        int r1, r2, r3, r4, zero=0;
        tmp=db+SIZE-1;
        r1=db-tmp;
        r2=tmp-db;
        r3=db-tmp+zero;
        r4=tmp-db+zero;
        printf(" db-tmp=%x tmp-db=%x\n db-tmp+0=%x tmp-db+0=%x\n",
                r1,r2,r3,r4);
        r1=0+db-tmp;
        r2=0+tmp-db;
        printf(" 0+db-tmp=%x 0+tmp-db=%x\n", r1, r2);
}

Here is the output:

 db-tmp=0 tmp-db=FFF09042
 db-tmp+0=F6FBE tmp-db+0=B
 0+db-tmp=F6FBE 0+tmp-db=FFF09042

I  find  the  results  to be somewhat inconsistent and confusing,
even  for  C!  It  looks  like  there  is  a serious problem with
pointer arithmetic.  

Try   to   write   anything  to  stderr  (printf(stderr,...).  or
puts(stderr,..),  or even write(2,...)).  The cursor drops down a
couple  lines  and  everything stops.  I found touching control C
at  least  got  me  out  of the program.  Version 3.03.02 did not
have this problem.  

I  opened  an  ASCII  text  file  for  level  1 input (open() and
read())  and  read  it  in.   I  got EOF before the file had been
completely  read.   Setting  ORAW in the open mode cleared things
up.  

In  the  area  of  clarification,  I think there are a few things
that must be made explicit in your manual: 

     I/O  redirection  on  a  program's command line must be done
     before  any  commands  to  the program (close examination of
     your  manual  shows  this,  but  many  people  familiar with
     systems like UNIX(tm), don't have that restriction).  

     > redirects stdout and < redirects stdin (see page 14) 

     There  can  be  no spaces between the redirection symbol and
     the file name.  

     When  compiling  a  program  that  uses  AES  and  VDI calls
     through  the  Lattice  library, do not use the -n option (31
     character  symbol  names),  because  the  library only has 8
     chararacter symbols; thus, the entries won't be found.  

Finally,  a  couple of questions.  How do you pass definitions to
a  compile?  The  -D option can set flags for #ifdef and #ifndef,
but  the  compiler  chokes  on parsing -dsymbol=value.  Last, but
not least, when is the next improved version due? 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The important point is that shar writes to stderr.  I found that changing
the fprintf(stderr,...) calls to cprintf(...) and fputs(...,stderr) to
cputs(...) solved things.

One last question for anyone on the net.  I heard at a users group meeting
that a patch exists for the Lattice library that permits I/O redirection
under the Beckemeyer Micro C-Shell.  Does anyone have that patch and if so,
could I get a copy?

Rodney Black
AT&T Information Systems
11900 North Pecos
Denver, CO 80234
..ihnp4!druxu!rwb