Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site que.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!que!chris From: chris@que.UUCP (Chris DeVoney) Newsgroups: net.micro.pc,net.lang.c Subject: Re: Eco-C Compiler Message-ID: <401@que.UUCP> Date: Fri, 2-Aug-85 09:55:55 EDT Article-I.D.: que.401 Posted: Fri Aug 2 09:55:55 1985 Date-Received: Sat, 3-Aug-85 06:14:09 EDT References: <436@bbnccv.UUCP> Distribution: net Organization: Que Corp, Indianapolis Lines: 50 Xref: watmath net.micro.pc:4790 net.lang.c:5891 John Lowery wrote about the Eco-C compiler in article <436@bbnccv.UUCP). Knowing the product very well (and I admitt some prejuice, the authors are close friends of mine), I will reply. > 1. It is true that the parser barfs on "printf (...)" and not on > "printf(...)". (note the space). You're right, he doesn't like it, but he need not accept it. K&R don't say it's ok to put a space between the function name and parens, ANSI don't say it okay, and I just avoid the practice. Oh, well. (Flames expected). > 2. Functions may be a little different. From examples in K&R > putc() uses an int c;. putc() in Eco-C expects a char. Per C spec., any function argument passed as a char goes to an int. Eco does do this. The library for version pre 2.71 was closer to V7. The current release is darn close to SysV. You are right that the documentation has a couple of mislabled argument. > 3. The compiler hates my ramdisk. You got me on this one. Tim Leslie, the author, has been running the compiler off of VDISK in DOS 3 and has no problems. I think there is some hostile interaction between Quadram's ramdisk program and Eco. Tim suggests you send me a copy of the program and he'll check it out. He gets additional memory from the DOS alloc/dealloc memory function calls, not the BIOS. Maybe there is some problem between the ramdisk, Eco-C, and DOS. > 4. Included below is a (large) fragment of code that will compile > fine but will not open and read the correct file. It took me about two readthroughs to figure this one out. fopen() is not declared in pswitch(). Eco treats pointers differently than integers. A return value of a pointer comes back in a different register. Hence, you're getting back a nonsense value from fopen() becuase the compiler is return an integer and not a pointer. Starting with V2.71 of the compiler, Tim has the Sys V function declarations in the header files. You might check with Ecosoft about upgrading to the later version. -- Chris DeVoney voice: 317/842-7162 Que Corporation uucp: ihnp4!inuxc!que!chris Indianapolis, IN #include /* you know what these are for */