casts to (void)

[Doug Gwyn <gwyn>]

> > The reason why not is, you have to limit yourself to a fairly puny
> > common subset and implement your own replacements for such useful
> > functions as drand48(), hsearch(), tempnam(), getopt(), etc. etc.
> 
> Our native library doesn't have drand48, hsearch or getopt, and tempnam is
> just a throwback to the days before sprintf.

I SAID that if you stick to a lowest common denominator, you would not
be able to use these nifty functions.  (Judging by your remark, I don't
think you know what tempnam does.)  If you really enjoy re-implementing
almost everything from scratch, more power to you, but I think it's
uneconomical.

> > Also, it is hard to use the basic utilities via popen() since they
> > don't behave the same in many cases.  You also cannot exploit the
> 
> I don't use popen either. It doesn't run on non-UNIX systems.
> 
> > more powerful features of "make", you have a "ranlib" problem, etc.

These comments were specifically directed at the problems of developing
code for a UNIX-like target system (I had 4.2BSD in mind) if a standard
environment is not available.

You could even provide substantially the same environment on your MS-DOS
system.  The Software Tools Users Group has shown the way.  I did this
once for a RSTS/E system, which is not inherently very much like UNIX,
and two or three times for variants of UNIX.

Are you aware of the current efforts to generate (international)
standards for a portable operating system interface?  This should make
the application developer's work much easier in the long run.