cwr@pnet01.cts.com (Will Rose) (06/01/91)
The recently posted what.c showed a glitch (I think) in the library.
It compiles with vfprintf missing, and this routine is called by
Ansi/vsprintf; however, vfprintf itself is in Curses, which is not
as far as I know part of the standard libc.a. I've also had problems
recently with the fdopen routine (as in, it didn't work); but I've not
looked at it closely enough to know whether it's me, or the library code.
Interestingly, the "new" tsort in the same posting hung forever (well,
two or three minutes) when compiled on an IBM PC running standard
1.5.10. There seems some sort of malign curse on tsort; I must have
seen five or six versions for Minix, and the only remotely reliable
one is the one for 1.5.10, *with* the official patch. And I'm not
altogether sure of that one. When you think of the amount of fairly
skilled programming effort that must have gone into all those versions,
you begin to wonder if dijkstra isn't right, we've simply changed problems.
There was also something strange about the tar file of that posting -
the files unpacked totalled ~25K, while the archive itself was ~40K
(from memory). I had another archive recently that showed a similare
effect, tho' not so marked. Is this a 'feature' of minix tar? I don't
think all tars have that sort of overhead.
Good luck - Will
-----------------------------------------------------------------------
I am | Will Rose
A) seldom | UUCP:{nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr
B) occasionally | ARPA:crash!pnet01!cwr@nosc.mil
C) often startled by a fish | INET:cwr@pnet01.cts.com
UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr
ARPA: crash!pnet01!cwr@nosc.mil
INET: cwr@pnet01.cts.com