Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!usc!ucsd!ucbvax!bloom-beacon!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.unix.aix
Subject: Re: Problems with popen on RS/6000
Keywords: popen, C, vmstat
Message-ID: <1990Aug23.133020.11170@world.std.com>
Date: 23 Aug 90 13:30:20 GMT
References: <1990Aug15.203239.8832@eplrx7.uucp>
Organization: Saber Software
Lines: 85

mroz@eplrx7.uucp (Peter Mroz) writes:
>I'm having a problem with popen sending back buffered output.

There is a general problem with many utilities when their output is
piped or redirected where output will be buffered unexpectedly.

For kicks sometime, try redirecting a make that contains multiple
files with errors to a file.  You'll get all the errors from cc,
followed by all the "cc" lines from make.  Make appears to buffer its
output until termination.  This also happens when piping to a pager.

The problem with this is that xlc doesn't emit information about which
file it's compiling so it's impossible to deterimine which files the
errors came from unless the cc lines are emitted before the errors.

The only way I could work around this problem was to use "script"
(which, thank God, does exist on the rios) to record make output.

This problem exists under 9021F.  I haven't tried it with the 3001
update applied.

A note to whomever in IBM does compiler output:  the default error
output of the compiler is the worst I've ever seen.  It's usually
ambiguous as to which file generated the error.  Try the following:

-- foo.h --
/* header file that contains an error
 */
int i j;
-- foo.c --
#include "foo.h"
main() {
int i j;
}
-- end --

It's largely guesswork to find which file the error came from since
there is no obvious indication of where foo.h's errors stop and
foo.c's begin.

Another fun one:

-- cut here --
% touch foo.h
% cat >foo.c
#include foo.h
main()
{
  printf("hello world\n");
}
^D
% cc foo.c
-- cut here --

Cc will tell you that an include file is empty but it shows the line
from foo.c, which is blank.  It took me awhile to figure out exactly
what it was talking about since when I ran across this one the include
file was within another include file and (as I said before) it's hard
to tell which file generated any particular error.

The error reporting done by xlc is fine if you're perusing a compiler
listing (eg using -qsource) but:

	* generating the source listing isn't the default
	* nobody wants to look through the entire source of their
	  160,000 line program to find their errors.

Those kinds of error messages were exceptable when you were dealing
with a 5,000 line RPG program, but we're in the real world now with
real world sized projects.  I don't have the time to look through more
than a quarter million lines of compiler output to find my errors, and
the default output is next to useless.

The cute little character pointers under the source line are only
mildly useful.  What I really want is to be able to easily tell which
file and line my error was on.  A simple "file.c, line 9: syntax
error" is much less ambiguous!

Someone please take heed and fix this problem or at least give the
option to produce more-or-less standard cc error messages that can be
parsed by human beings reliably.  Right now it's virtually useless.

jim frost
saber software
jimf@saber.com