de5@ornl.gov (Dave Sill) (03/13/91)
Running doit.bin, I get the following error:
+ cd ../libcnews
+ make u COPTS=-O
cc -O -I../include -c string.c
(ccom): string.c, line 135: ccom: Internal: wasted space: 2001731410
}
^
Anybody know what the problem is, or if there's a workaround? This is
the current (Dec 15 '90) version od C-news.
--
Dave Sill (de5@ornl.gov) It will be a great day when our schools have
Martin Marietta Energy Systems all the money they need and the Air Force
Workstation Support has to hold a bake sale to buy a new bomber.henry@zoo.toronto.edu (Henry Spencer) (03/14/91)
In article <1991Mar13.123949.5826@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >cc -O -I../include -c string.c >(ccom): string.c, line 135: ccom: Internal: wasted space: 2001731410 > } > ^ >Anybody know what the problem is, or if there's a workaround? ... Read "Values of Logical Operators" in notebook/problems. -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry
de5@ornl.gov (Dave Sill) (03/15/91)
In article <1991Mar13.162056.19587@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1991Mar13.123949.5826@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >>cc -O -I../include -c string.c >>(ccom): string.c, line 135: ccom: Internal: wasted space: 2001731410 >> } >> ^ >>Anybody know what the problem is, or if there's a workaround? ... > >Read "Values of Logical Operators" in notebook/problems. Thanks, that was the problem alright. But... Even though I read the problems file, and even that section, I made no connection between the problem described and my symptom. The only obvious connection was the mention of Ultrix. Perhaps if the "Values of Logical Operators" section included the above error message I would have caught it. But this begs a larger question: If you knew that some systems bombed on the *p++ = isascii(c) && isalnum(c); line, why didn't you just change it to *p++ = (isascii(c) && isalnum(c)) ? 1 : 0;? Is this just a stubborn refusal to "clutter" your code at the expense of those who have to make it work? If it is, I think you've made a terrible mistake. I've got more C-news (and NNTP) gripes, but they deserve their own article. -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.
henry@zoo.toronto.edu (Henry Spencer) (03/17/91)
In article <1991Mar15.124555.10361@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >Even though I read the problems file, and even that section, I made no >connection between the problem described and my symptom... There is a well-known principle, which I would have hoped everyone would be aware of, that really cryptic "something went badly wrong here" complaints from compilers are often delayed a few lines, especially if those few lines are mostly things like closing braces. If your compiler dies in agony, blindly looking only at the line *it* thinks caused the problem is just not enough. By definition, it is confused. At some point, there will be a "Troubleshooting Guide", which probably should include a "Novice's Guide To Compiler Problems" section. Note that it won't happen soon unless somebody else gets interested in writing it, because we think our scarce time is better spent right now on the code. >... Perhaps if the "Values >of Logical Operators" section included the above error message I would >have caught it. And what if DEC changes the format of the message next time? Pinning down compiler errors inherently requires thought; we don't think it is our job to try to provide cookbook solutions for every problem, especially when it means tracking vendor brain-damage in detail. >But this begs a larger question: If you knew that some systems bombed >on the line, why didn't you just change it... >Is this just a stubborn refusal to "clutter" your code at the expense >of those who have to make it work? If it is, I think you've made a >terrible mistake. No, it is a stubborn refusal to try to program around the brain damage of every broken compiler in existence. In this case, the effort is relatively minor and we might get around to it, although we don't class it as urgent and we have a lot to do. However... In general, trying to program in lowest-common-denominator C is like programming in BASIC. Refusing to do this is not a "terrible mistake", it is a practical necessity. We have more important things to spend our time on. The vast majority of "those who have to make it work" do *not* have this particular bug. We think our time is best spent on work that will benefit everybody, and there is a lot of that. Don't forget to complain to your compiler supplier. -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry