Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Portability
Keywords: PORTABILITY
Message-ID: <11013@smoke.BRL.MIL>
Date: 9 Sep 89 09:28:34 GMT
References: <116@quame.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 51

In article <116@quame.UUCP> bryan@quame.UUCP (Bryan A. Woodruff) writes:
>I have noticed a certain amount of care taken towards the "portability"
>aspect of C...  When C was designed, was it not the idea to have a completely
>portable language from system to system?

No, C was designed as a system implementation language for UNIX
on one particular machine (PDP-11).  Its designer was sufficiently
careful in specifying an abstract language that it turned out to
be implementable on a wide range of other architectures, although
some nagging inconsistencies were not resolved until the ANSI
standardization process.

Many programmers discovered that it was not only possible to
write extremely architecture-specific applications such as OS
device drivers in C, but it was actually possible with a modest
amount of care to write C applications that were highly portable
across different operating systems and machine architectures.
The "standard I/O library" contributed substantially to this.

Portability of applications is important, but it is not everything.

>Do not all systems have a tree directory or some other directory
>structure?

No.

>Why then are there not portable functions for accessing the
>directories?

There are, for limited classes of operating systems (e.g., POSIX
specifies one such set, a public-domain UNIX version of which I
maintain and send out on request).

>I want to write a module that has the ability to access a directory
>(read, create, cd, etc...) without having to worry about the
>operating system (i.e. MS-DOS, UNIX, (flavors), XENIX, etc)

The POSIX interface, augmented by mkdir(), rmdir(), etc. would be
a good starting place.  Unfortunately, some OSes don't fully support
all these operations.  (Some don't support any of them.)

>When is C going to be completely portable, without having to worry about
>#IFDEF's????

When are all operating systems going to act identically?

By the way, it's not necessary to sprinkle #ifdefs liberally through
your code.  You should try to isolate system dependencies in separately
compiled plug-replaceable modules, so the main application code does
the same thing in all environments, calling on support functions that
themselves are tailored to the specific environment.