Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!ira.uka.de!smurf.sub.org!news
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.os.386bsd.development
Subject: Re: POSIX, compatibility with (was: Re: File Truncation Philosophy
Date: 30 Apr 1993 09:36:57 +0200
Organization: University of Karlsruhe, FRG
Lines: 23
Message-ID: <1rqkup$ag3@smurf.sub.org>
References: <1993Apr28.031049.27996@fcom.cc.utah.edu> <1993Apr28.113238.13749@klaava.Helsinki.FI> <1993Apr29.210327.27310@fcom.cc.utah.edu>
NNTP-Posting-Host: 127.0.0.1
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
In comp.os.386bsd.development, article <1993Apr29.210327.27310@fcom.cc.utah.edu>,
terry@cs.weber.edu (A Wizard of Earth C) writes:
> In article <1993Apr28.113238.13749@klaava.Helsinki.FI> lukka@klaava.Helsinki.FI (Tuomas J Lukka) writes:
> >Posix explicitly states that implementations may return errors
> >not specified in the document or may have extensions or something
> >that prevent an error specified from being returned ...
> >Look at section 2.4
>
> Any extension we make, whether or not allowed, and expecially to fundamental
> services like process creation, risks our ability to run strictly compliant
> programs. [...]
I submit that any program which crashes&burns when confronted with a
non-POSIX error code from _any_ system call does not adhere to the
aforementioned Section 2.4 and thus is not strictly POSIX compliant
in the first place. ;-)
--
Hinds' Fourth Law of Computer Programming:
Any given program will expand to fill all available memory.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/