On Mon, Aug 06, 2012 at 06:09:08PM -0400, Ben Walton wrote:
> > I'm currently in pkgutil hell trying to remember how to get a working
> > gcc on Solaris. Bleh. What kind of OS doesn't ship with a compiler by
> > default? :)
>
> One that's losing mindshare and isn't gaining traction? *g* Feel free
> to message me offline if you need a hand with that.
Thanks, I figured it out (I installed opencsw's gcc, but I had no
standard include files. Turns out that I needed the system/header
package from upstream).
The stdio behavior on Solaris is weird. If I run this sample program:
#include <stdio.h>
int main(void)
{
FILE *fh = fopen("/dev/tty", "w+");
char buf[32] = {0};
fgets(buf, sizeof(buf), fh);
fprintf(fh, "got %s\n", buf);
return 0;
}
on Linux, I get:
$ ./a.out
foo <-- me typing
got foo <-- program output
On Solaris, I get:
$ ./a.out
foo <-- me typing
foo <-- ???
got foo <-- program output
If you step it through the debugger, the mystery output comes as part of
the fprintf, as if it is in the buffer waiting to be flushed. And
indeed, if you dump the FILE handle via gdb, there is only a single
buffer, and it contains "foo\n". Whereas with glibc, there are separate
read/write buffers.
I suspect the single buffer is enough to handle normal files, but not
bidirectional pipes where the input and output content are unrelated. I
don't think Solaris is _buggy_ per se, as we have probably stepped
outside the realm of what the standard promises, but it's certainly a
quality-of-implementation issue.
So I think it could be solved by opening /dev/tty twice (or fdopen()ing
the same descriptor twice). Or by just doing away with stdio entirely.
Looking over the code, I recall now why I used stdio: strbuf_getline
requires it. These days we have strbuf_getwholeline_fd. It's slightly
less efficient (it has to read() a character at a time), but since we
are talking about a few characters of keyboard input, it should be OK.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html