peterc@softway.oz (Peter Chubb) (08/29/89)
Some more bugs in Lattice C 5.02 for the Amiga for your pleasure and
delectation:
Compiler bug:
void t()
{ long a, *t;
*t = (*t < a);
}
Instead of a compare instruction, the compiler generates an exclusive or
instruction. These have the same bit pattern, but are interpreted
differently depending on the addressing mode.
Library bugs:
getenv() seems to use the same buffer for the name of the file in env: and
its returned contents. Unfortunately, if the file name was longer than the
value of the variable, the end of the file name will still be visible.
Maybe it's not being null terminated properly?
I've appended a version of getenv that works. This version uncovered a bug
in the builtin_strcpy, too!
fork() often seems to crash the amiga. Try the example in the manual with
c:echo as argument, just be ready for the three-fingered reset.
----------------Cut Here------------------------------------
/************************************************************************
* getenv.c -- get environment variable value. *
* *
* Copyright 1989 Peter Chubb *
* All rights reserved *
* *
* This software may be used and distributed freely *
* providing this notice is not removed or altered *
* and any changes to the file are clearly marked as *
* such. *
* *
************************************************************************/
#include <stdio.h>
#include <string.h>
#include <proto/dos.h>
#undef strcpy /* avoid bug in built_in strcpy */
/* getenv -- return value of 1.3 environment variable */
char *
getenv(char *name)
{
static char buf[BUFSIZ];
BPTR envfile;
long len;
if(!name)
return NULL;
(void)strcpy(buf, "ENV:");
(void)strcat(buf, name);
if((envfile = Open(buf, MODE_OLDFILE)) == (BPTR)0)
return NULL; /* non-existent variable */
if((len = Read(envfile, buf, BUFSIZ)) < 0){
(void)Close(envfile);
return NULL;
}
if(len != BUFSIZ)
buf[len] = '\0';
else /* too long */
buf[BUFSIZ-1] = '\0';
(void)Close(envfile);
return buf;
}dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (08/30/89)
:fork() often seems to crash the amiga. Try the example in the manual with
:c:echo as argument, just be ready for the three-fingered reset.
You cannot fork() a BCPL program, period.
Also, I don't think you can call Execute() from a fork()'d program
but am not sure. Apart from those problems, fork() makes multitasking
on the Amiga easy!
-Mattprem@geomag.fsu.edu (Prem Subrahmanyam) (08/31/89)
This is a serious bug I've discovered while working with
DBW_Render. The two following statements should be the same,
right?
for (i=0; i < something; i++)
/* insert command to loop here */ ;
for (i=0; i < something; i++) {
/* same command as before */ ;
}
the only difference is that the second statement has a begin and end
bracket, while the first one does not. Albeit, this is not impossible
to work around, but it sure makes it a pain to work on any program
written for any other compiler 'cept Lattice. By the way, the second
statement always works properly, while the first one is sort of hit
and miss, sometimes they work, sometimes not. I have spent 2 whole
weeks trying to fix the marble texture in DBW due to just this problem.
I would not have guessed such a basic bug would be there causing problems...
so I would go looking at every function and dumping all kinds of values.
All I did to make it work was to insert the braces in place and voila.
I'm not at all saying that I don't like the Lattice environment. I really
like LSE, the addition of Conman, PopCLI, etc, and I really like the
product, however, it seems that there are a lot of problems due to
incomplete testing prior to release. I hope that fixes for this very
trivial bug will be quickly forthcoming, as I have planned on porting
C programs written in a UNIX environment and don't want to have to go
rooting through the code for all the for() statements and put begin/end
braces after each one. This should not be for what claims to be an ANSI
compatible compiler!!!!!
---Prem Subrahmanyam (prem@geomag.gly.fsu.edu)tim@praxis.co.uk (Tim Magee) (08/31/89)
I'm a bit of a late entrant in this. Has anyone spotted:
struct _ffbb { int flim, flam, bim, bam; };
struct _ffbb bimble ( x )
struct _ffbb x;
{
return x;
}
Then try two loops, one of which contains a single call
of bimble(), the other two consecutive calls. The one with
two calls brings out the imperialistic tendencies in your
stack. It looks very pretty in CattlePRod(tm).
tim
--
-- Tim Mageegrwalter@watmath.waterloo.edu (Fred Walter) (09/03/89)
In article <142@vsserv.scri.fsu.edu> prem@geomag.gly.fsu.edu (Prem Subrahmanyam) writes: > The two following statements should be the same, right? > > for (i=0; i < something; i++) > /* insert command to loop here */ ; > > for (i=0; i < something; i++) { > /* same command as before */ ; > } No, they are not the same. If your command is a macro, the macro expansion may be such that only part of the command is in the loop in the first case. (This has bitten me before). Not saying that the above isn't a problem in Lattice, but any bugs I've had with the above were in my code (with a macro expanding with part of the command out of the loop). fred
prem@geomag.fsu.edu (Prem Subrahmanyam) (09/04/89)
I have received many replies concerning my problem being dealing with
a macro and have looked very carefully to see if this was the problem.
Here is the exact code that I had (I have actually had it even work
improperly after adding brackets as well, now....I'm beginning to suspect
that I need to try to just recopy my disks);
/* do lots of stuff to a variable called texture */;
for(i=0; i < squeezevalue; i++)
texture = texture * texture;
and then with brackets, it works more often, but not always (recompiling
before every run--I'm trying to rewrite the program).
I will post more fully the entire section of code, what I did to fix it,
and my theories as to what could have happened in a later article.
For now, this is all.
---Prem Subrahmanyamwalker@sas.UUCP (Doug Walker) (09/05/89)
In article <28855@watmath.waterloo.edu> grwalter@watmath.waterloo.edu (Fred Walter) writes: >Not saying that the above isn't a problem in Lattice, but any bugs I've had >with the above were in my code (with a macro expanding with part of the >command out of the loop). If it IS a bug, please PLEASE report it to Lattice Tech Support in a reproducible manner! I can't reproduce it based on your posting. I suspect the macro expansion problem Fred mentioned might be biting you. I personally use the style for(;;) stmt all the time, and I have NEVER had a problem. --Doug
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/09/89)
In article <142@vsserv.scri.fsu.edu> (Prem Subrahmanyam) writes:
-> This is a serious bug I've discovered while working with
-> DBW_Render. The two following statements should be the same,
-> right?
->
-> for (i=0; i < something; i++)
-> /* insert command to loop here */ ;
->
-> for (i=0; i < something; i++) {
-> /* same command as before */ ;
-> }
This works fine for me. Are you using the optimizer on this code? There
are some serious optimizer bugs that got fixed in 5.04 (which is due
out RSN according to Jtoebes at a recent BADGE meeting) and to get the
update will require that you call Lattice and ask for it.
Can you at least give compiler switches you used and maybe make a small
test case that demonstrates the problem ?
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"If I were driving a Macintosh, I'd have to stop before I could turn the wheel."