[comp.sys.apple2] Orca/C, bug?

duerksen@bsu-cs.bsu.edu (Joel L. Duerksen) (10/17/90)

The program below crashes on my computer....  Most compilers would
complain about the 0.0 and would require explicit type casting.
Orca/C compiles it just fine.  The value of the double doesn't seem
to matter, except sometimes the integer will get weird values instead
of crashing the program.

ps. I don't normally subtract zero from numbers :-)   I found this
    while trying to port a piece of generic C code.

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

#include <stdio.h>
#include <stdlib.h>

void main(void)
{
     int i;

     i= 50;
     i -= 0.0;
     printf("i=%d\n", i);
}



Joel Duerksen

USnail: 410 N. McKinley, Apt. 305, Muncie, IN. 47303 
  AT&T: 1-317-289-0430  ICBM: 85 24 31 W / 40 12 16 N   RF: KB9EKY
  UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!duerksen
  ARPA: duerksen@bsu-cs.bsu.edu

toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/18/90)

Well, I just tried it, and yes, it's a bug. Hopefully someone will have caught
this and fixed it in the 1.1 update, if not then we ought to get in touch with
byteworks and let them know that the type casting code has a bug in it.

Todd Whitesel
toddpw @ tybalt.caltech.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/18/90)

In article <11906@bsu-cs.bsu.edu> duerksen@bsu-cs.bsu.edu (Joel L. Duerksen) writes:
>The program below crashes on my computer....  Most compilers would
>complain about the 0.0 and would require explicit type casting.

No, they would not.  The C language requires that compilers happily
accept the construct "i -= 0.0", which means "convert i to double,
subtract 0.0, convert back to int, and store into i".

I have no doubt that some compilers get this wrong, but if so it is
a bug in the compiler.

toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/18/90)

jb10320@uxa.cso.uiuc.edu (Desdinova) writes:

>   Orca DOES require a typecast.  But it doesn't complain. One of the
>biggest problems with ORCA is it's lack of error messages, or inappropriate
>error messages.  It's makes programming difficult sometimes.

Funny... I've found the error messages to be a fairly good safety net.
The only three things I'd run into before this were the structure auto-
initialization bug, a problem with using fread and fwrite (i.e. they trash
memory in subtle ways), and an inability to declare a pointer to void as a
normal variable or element of a structure (ANSI K&R is a little vague on
whether you can actually do that -- anybody know?).

Todd Whitesel
toddpw @ tybalt.caltech.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/19/90)

In article <1990Oct18.023155.17388@nntp-server.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:
>... an inability to declare a pointer to void as a
>normal variable or element of a structure (ANSI K&R is a little vague on
>whether you can actually do that -- anybody know?).

If you mean, is
	struct { void *p; };
permitted in a strictly conforming program, then the answer is,
of course it is.  It doesn't have to be specifically mentioned
in K&R 2nd Edition because it follows naturally from the rules.

toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/19/90)

jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) writes:

>1.)  Never declare main as void.  Main returns an int.

Um, I have been writing void main (...) without problems ever since I
got ORCA (over 1 month of extensive use). If I declare main as void then
everything works; if I try to return something from main I get an error
because main is declared to return void.

In actuality, 1 thru 4 byte values are returned in registers, so it
doesn't really matter as far as code generation is concerned unless
you are returning a struct or a float.

BTW- I am still using a beta.

Todd Whitesel
toddpw @ tybalt.caltech.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/20/90)

In article <1990Oct19.133843.26089@nntp-server.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:
>jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) writes:
>>1.)  Never declare main as void.  Main returns an int.
>Um, I have been writing void main (...) without problems ever since I
>got ORCA (over 1 month of extensive use). If I declare main as void then
>everything works; if I try to return something from main I get an error
>because main is declared to return void.

Jeffrey is correct.  Since main() is expected to return an integer,
it had better do so.  Otherwise the C runtime startup code could get
tangled up when it tries to use the (nonexistent) value.  It may be
that a particular version of a particular compiler does not create
code that runs entirely amok when your program attempts this sort of
abuse, but you shouldn't rely on that.  Do it right and avoid
potential problems.

toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/20/90)

ORCA/C manual, ch. 13 "C Programs", p. 205:

"You may declare the function main as either a function returning an integer or
as a function returning void."

Sorry to nitpick.

Todd Whitesel
toddpw @ tybalt.caltech.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (10/21/90)

In article <1990Oct19.232345.5653@nntp-server.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:
>"You may declare the function main as either a function returning an integer or
>as a function returning void."

But do it right anyway.  You might someday want to compile your code using
a compiler where it matters.

jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/25/90)

toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:

>ORCA/C manual, ch. 13 "C Programs", p. 205:

> "You may declare the function main as either a function returning an
> integer or as a function returning void."

Yes, you may.  If you want to continue using ORCA/C on a IIgs the rest
of your life.  But what happens when you port it to a machine that
doesn't follow this rule?  You know as well as I do that the ORCA/C
manual is not the definitive source on C.
-----------------
Jeffrey Hutzelman
America Online: JeffreyH11
Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu,
                jh4o@cmuccvma

>> Apple // Forever!!! <<