*BSD News Article 34126


Return to BSD News archive

Xref: sserve comp.windows.x.i386unix:11081 comp.os.386bsd.apps:1339 comp.os.386bsd.questions:12243
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!xmission!u.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (Terry Lambert)
Newsgroups: comp.windows.x.i386unix,comp.os.386bsd.apps,comp.os.386bsd.questions
Subject: Re: __NetBSD__ X11R6 i386
Date: 3 Aug 1994 21:40:43 GMT
Organization: Weber State University, Ogden, UT
Lines: 39
Message-ID: <31p2sr$ikj@u.cc.utah.edu>
References: <deeken.775902001@iti.informatik.th-darmstadt.de> <31nqad$mii@news.rhrz.uni-bonn.de> <31olij$61a@news.rhrz.uni-bonn.de>
NNTP-Posting-Host: cs.weber.edu

In article <31olij$61a@news.rhrz.uni-bonn.de> juengst@saph2.physik.uni-bonn.de writes:
] BUT, this header file will be only included on POSIX systems. If one
] does _not_ define X_NOT_POSIX, then imake.c defines _POSIX_SOURCE
] (forget WIN32 for a moment - or much longer... :-) Now, if imake.c
] defines itself as POSIX source, then unistd.h, which I didn't found
] in two ANSI C books as standard header file, will be included. In
] unistd.h of NetBSD-current you can see that ftruncate will be NOT
] declared if _POSIX_SOURCE was defined. And I think ftruncate is not
] a posix function. I didn't find it in any book as posix compatible
] function (I found other functions successfully), but I'm afraid I don't
] have POSIX1003.1(?) here. If anybody has this "standard" it would be
] funny to know if it is a posix function.

Some behaviours are excepted specifically for Berkeley ftruncate()
behaviour.  This is described in Appendix B of the standard.

The ftruncate interface itself is not defined by the standard; in fact,
in most modern implementations (which support file extension as well as
truncation interfaces), this is done by fcntl(), and ftruncate(), if it
is provided, is a library routine instead of a system call.  This is
precisely what AIX and SVR4 both do -- and is damned inconvenient in
AIX if you are using the fp_ routines for kernel space file I/O.  It
isn't impossible to work around, but it's very, very close.

Appendix B of POSIX also excepts some behaviour for SVR4 file extension.

In POSIX proper, it is not possible to do anything to the file size
through a defined interface (other than to ask what it is).  This is
one of the many deficiencies of the specification, and why you really
couldn't write a working OS to the spec (remind me to see what Linux
does about file truncation and extension -- one would expect it to do
nothing).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.