Unix/C program modularity

[Paul van de Graaf]

The problem here is not a question of programmers forever reinventing the wheel,
but rather a lack of uniformity of the various flavors of Unix.  Most defensive
programmers take into account that the programs they write might be ported to
v6 or XENIX or even a micro that only has an incomplete implementation of the
stdio package (if that much).  Writing a program with a myriad of fancy pipes
and filters may be faster and easier, but if you don't want to go the extra
mile to write emulations of certain system calls and a lot of ugly #ifdefs, 
you're going to lose if you try to port. 

The GNU project, the ANSI C standardization commitee, and the /usr/group people
are all working on this problem from different directions, so don't expect an
answer too soon.  The GNU effort has great promise, because it could act as a
clearinghouse for all those system-call emulators.  Whether this fits in with
their plans, I can't say, but I'd love to be able to call them up and get the
102nd version of getopt() for my Hal 9000 for a nominal charge.  I kind of feel
the ANSI C people decided that it was boring to standardize C, so they spilled
over into Unix interface standardization.  C and Unix aren't always synonymous,
especially on micros:  witness the Amiga and the Atari ST.  If they don't stay
on track, they may jeapordize their whole standard.  The /usr/group folks talk
a lot, but nobody listens... they're JUST a user group anyway :-)!

Tough decisions need to be made in order to come up with a standard.
In the meanwhile, I'm coding defensively.

Paul van de Graaf	   sdcsvax!sdcc7!ln63fkn		U. C. San Diego