Portability

[Doug Gwyn]

In article <116 at quame.UUCP> bryan at 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.