dlong@sdsu.UUCP (Dean Long) (12/26/86)
Try these two commands on a 3b2 running SYSV unix on the following program:
cc -c sub.c # should work OK
cc -DCRASH -c sub.c # /lib/ccom should core dump
Does anyone have any ideas?
----------------------------------------------------------------------
sub()
{
char x;
int i;
i = ((x > 0) ? 1 : 0);
i = ((x >= 1) ? 1 : 0);
#ifdef CRASH
i = ((x >= 0) ? 1 : 0);
#endif
}
--
Dean Long
San Diego State Univ.
sdcsvax!sdsu!dlongkimcm@olamb.UUCP (Kim Chr. Madsen) (12/31/86)
In article <2489@sdsu.UUCP>, dlong@sdsu.UUCP (Dean Long) writes: > Try these two commands on a 3b2 running SYSV unix on the following program: > > cc -c sub.c # should work OK > cc -DCRASH -c sub.c # /lib/ccom should core dump > > [some code].... Well, tried this one out without any problems on this 3b2 running UNIX System V R2.1 are you running Release 3 or an older (pre 2.1 release) system V. The only thing that really bugs me is the fact that chars are unsigned and therefore the following code will fail: while ((c=getc(stream)) != EOF) putchar(c); And you will have to redefine EOF to 255 (0377 or 0xff) or cast it to a char! Kim Chr. Madsen
jrw@hropus.UUCP (Jim Webb) (01/02/87)
> The only thing that really bugs me is the fact that chars are unsigned > and therefore the following code will fail: > > while ((c=getc(stream)) != EOF) putchar(c); > > And you will have to redefine EOF to 255 (0377 or 0xff) or cast it to a char! Ummm. I always declare c as an int, not a char, and everything works fine and dandy... -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Make sure comments and code agree. If not, write a man page..."
james@bigtex.uucp (James Van Artsdalen) (01/02/87)
IN article <189@olamb.UUCP>, kimcm@olamb.UUCP (Kim Chr. Madsen) wrote: > The only thing that really bugs me is the fact that chars are unsigned > and therefore the following code will fail: > > while ((c=getc(stream)) != EOF) putchar(c); > > And you will have to redefine EOF to 255 (0377 or 0xff) or cast it to a char! This code will fail no matter how chars are handled, assuming "c" is a "char". If you remember that getc() returns an *int*, not a char, and have "int c" instead of "char c", this works just fine. If "c" is declared "char c;", the while loop above is broken even with signed chars: what happens to the while loop if a 0xff is in the file? It terminates early, whereas if c is "int c;" is works OK. lint will find this kind of bug. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Voice: (512)-323-2675 Modem: (512)-323-2773 5300B McCandless, Austin TX 78756
aeusemrs@csun.UUCP (Mike Stump) (01/04/87)
In article <189@olamb.UUCP> kimcm@olamb.UUCP (Kim Chr. Madsen) writes: >In article <2489@sdsu.UUCP>, dlong@sdsu.UUCP (Dean Long) writes: >> Try these two commands on a 3b2 running SYSV unix on the following program: >> [edited for space] >Well, tried this one out without any problems on this 3b2 running UNIX >System V R2.1 are you running Release 3 or an older (pre 2.1 release) >system V. I tried it on 3b5 System V Version 2 release 2.0 and it bombs. Looks like they fix the problem in 2.1... Dean is probably running 2.0, like me. I will be happy when we upgrade to a 3b15, and S5V3... Mike Stump
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/05/87)
In article <189@olamb.UUCP> kimcm@olamb.UUCP (Kim Chr. Madsen) writes:
-The only thing that really bugs me is the fact that chars are unsigned
-and therefore the following code will fail:
- while ((c=getc(stream)) != EOF) putchar(c);
-And you will have to redefine EOF to 255 (0377 or 0xff) or cast it to a char!
I suspect there will be a zillion follow-ups explaining
that getc() returns an (int), not a (char), and that EOF
should remain defined as -1. This has been hashed over
many times in net.lang.c. It is not a bug in the 3B2 C
implementation.