Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: C on IBM MVS or VM/CMS
Keywords: C IBM mainframe request
Message-ID: <11724@smoke.BRL.MIL>
Date: 2 Dec 89 01:08:56 GMT
References: <249@dlogics.UUCP> <1989Dec1.000456.29060@agate.berkeley.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <1989Dec1.000456.29060@agate.berkeley.edu> bks@alfa.berkeley.edu (Brad Sherman) writes:
>Close() is a void function in WATCOM.  Is this reasonable?

It's not UNIX-compatible, but it's reasonable.

>Open() cannot take a third argument (mode).  As permissions are a
>non-sequitor under CMS this is reasonable, but could someone explain
>to me how this argument can be optional in a traditional C environment?

In general it cannot be; this was yet another in a continuing series of
C function interface design botches introduced into UNIX through the
years.  When AT&T decided to add O_CREAT functionality to the existing
(2-argument) open() system call, they made the kernel look at a third
argument if and only if O_CREAT were set in the second argument.  This
happened to work on VAX, PDP-11, and 3B UNIX implementations, but as is
well known it might not work in other environments.

UNIX applications developers who were concerned about this botch had
to guess how to deal with it.  Some of us assumed that open() would
be officially a 3-argument function, and modified older 2-argument
usage to provide a third argument (normally 0).

IEEE 1003.1 had to address this problem, and their solution was to
specify open() as a variadic function.