jlowry@bbnccv.UUCP (John Lowry) (08/01/85)
Despite my earlier posting praising Ecosoft's Eco-C Compiler, I
now have to add some warnings and complaints. (For $49.95 what did
I expect ...)
1. It is true that the parser barfs on "printf (...)" and not on
"printf(...)". (note the space). Frustrating but livable.
Only one I've found so far ...
2. Functions may be a little different. From examples in K&R
putc() uses an int c;. putc() in Eco-C expects a char.
3. The compiler hates my ramdisk. I have the QuadRam board and use
the supplied ramdisk. Because the compiler, library, header
files, linker, editor, etc. consume so much room, I have been
forced to use 3 floppies. I tried to load the compiler into the
ramdisk, and when it came time to link the ramdisk FAT was
trashed. So I tried to load the library into the ramdisk...
same problem. Apparently, the parser gets available memory from
BIOS and does all it's work at some offset from high memory.
Since this is where my ramdisk lives ... This means that you
can't use the 'make' function of the compiler or the auto-link
because there isn't enough room for all that is needed and your
sources. (I know, buy a hard-disk. Of course, if I could
afford a hard-disk, I wouldn't be playing with a $49.95
compiler.)
4. Included below is a (large) fragment of code that will compile
fine but will not open and read the correct file. Specifically,
this is part of a small nroff-like program that I got from a
BBS. The problems occur when the file name of the macro file is
passed to a function for reading. fopen() returns NULL
consistently. This fragment compiles on the Mark Williams
compiler, and two other mini-computer compilers, and runs. If
you can see what is questionable with this code, please respond.
After compiling, run with "nro -m<textfile>", same format
as loading a macrofile into nroff.
Header File: nroall.h -----------------------------------------
#define NFILES 4 /* nesting depth for input files */
#define ERR -1
#ifndef EXTERN
#define EXTERN extern
#endif
EXTERN FILE *sofile[NFILES]; /* input file buffers */
C Source File: nro.c ---------------------------------------------
/*
* Word Processor
* similar to Unix NROFF or RSX-11M RNO -
* adaptation of text processor given in
* "Software Tools", Kernighan and Plauger.
*
* Stephen L. Browning
* 5723 North Parker Avenue
* Indianapolis, Indiana 46220
*/
#include <stdio.h>
#define TRUE 1
#define FALSE 0
#define EXTERN
#include "nroall.h"
main(argc, argv)
int argc;
char *argv[];
{
int i,c;
int swflg;
int ifp, ofp;
FILE *fopen();
swflg = FALSE;
pout = stdout;
ifp = ofp = 0;
for (i=1; i<argc; ++i) {
if (*argv[i] == '-' || *argv[i] == '+') {
/* start of problem, here is the call */
if (pswitch(argv[i],&swflg) == ERR) exit(-1);
}
}
for (i=1; i<argc; ++i) {
if (*argv[i] != '-' && *argv[i] != '+' && *argv[i] != '>') {
if ((sofile[0] = fopen(argv[i], "r")) == NULL) {
printf("nro: unable to open file %s\n",argv[i]);
exit(-1);
}
else {
while((c=getc(sofile[0])) != EOF)
putchar(c);
fclose(sofile[0]);
}
}
}
if (argc == 1) {
puts("Usage: nro [-n] [+n] [-pxx] [-v] [-b] [-mmacfile] infile...[>outfile]\n");
exit(-1);
}
}
/*
* process switch values from command line
*/
pswitch(p,q)
char *p;
int *q;
{
int swgood, c;
swgood = TRUE;
if (*p == '-') {
switch (*++p) {
/* here is the offending(?) code. */
case 'm':
if ((sofile[0] = fopen(++p, "r")) == NULL) {
printf("***nro: unable to open file %s\n",p);
exit(-1);
}
while((c=getc(sofile[0])) != EOF)
putchar(c);
fclose(sofile[0]);
break;
default:
swgood = FALSE;
break;
}
}
if (swgood == FALSE) {
printf("nro: illegal switch %s",p);
return(ERR);
}
return(TRUE);
}
John Lowry
jlowry@bbnz
jlowry@bbnccvchris@que.UUCP (Chris DeVoney) (08/02/85)
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 <trademarks.all && disclaimer.all> /* you know what these are for */
bright@dataio.UUCP (Walter Bright) (08/03/85)
In article <401@que.UUCP> chris@que.UUCP (Chris DeVoney) writes: >John Lowery wrote about the Eco-C compiler in article <436@bbnccv.UUCP). > >> 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. C is a tokenized language, and since 'printf' and '(' are separate tokens, any amount of whitespace may appear between them. The only time that whitespace has to be handled in the definition of the language is in dealing with the preprocessor.
chris@umcp-cs.UUCP (Chris Torek) (08/04/85)
>>the parser barfs on "printf (...)" and not on "printf(...)". >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). ...and received: the problem was that the original wording was ambiguous. The *intent* is that any identifier followed by a left parenthesis, with nothing other than whitespace intervening, is a function call. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland