NetBSD Problem Report #10279

Received: (qmail 14440 invoked from network); 5 Jun 2000 01:54:20 -0000
Message-Id: <20000605015507.5053.qmail@mailhost.dave.dtsp.co.nz>
Date: 5 Jun 2000 01:55:07 -0000
From: dave@dtsp.co.nz
Reply-To: dave@dtsp.co.nz
To: gnats-bugs@gnats.netbsd.org
Cc: dave@dtsp.co.nz
Subject: Large File Summit API is not supported under NetBSD
X-Send-Pr-Version: 3.95

>Number:         10279
>Category:       lib
>Synopsis:       Large File Summit API is not supported under NetBSD
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 05 01:55:00 +0000 2000
>Closed-Date:    Tue Jul 12 02:45:53 +0000 2016
>Last-Modified:  Tue Jul 12 02:45:53 +0000 2016
>Originator:     Dave Sainty
>Release:        NetBSD-current early June
>Organization:
Dynamic Technology Services and Products Ltd (NZ)
>Environment:
System: NetBSD tequila.dave.dtsp.co.nz 1.4R NetBSD 1.4R (TEQUILA) #3: Wed Feb 16 20:01:31 NZDT 2000 dave@tequila.dave.dtsp.co.nz:/vol/tequila/userB/u2/NetBSD-current/src/sys/arch/i386/compile/TEQUILA i386


>Description:
	http://ftp.sas.com/standards/large.file/x_open.20Mar96.txt
	http://ftp.sas.com/standards/large.file/x_open.20Mar96.addendum.html

	The Large File Summit API is (I'm told) supported by recent Solaris's,
	Irix, Linux and possibly others (given the list of companies in
	attendance).  One might question whether the LFS
	approach is correct.  But... not supporting it still
	generates a porting issue with programs that expect the API to be
	available.

	On NetBSD the effort required to support the API is fairly minimal.
	Possibly no kernel changes.

	As a sample, the API looks like (from the first URL above):

3.1.1.1.2 STDIO Interfaces

fgetpos64()            fopen64()
freopen64()            fseeko64()
fsetpos64()            ftello64()
tmpfile64()

3.1.1.1.3 Other Interfaces

creat64()             fstat64()
fstatvfs64()          ftruncate64()
ftw64()               getrlimit64()
lockf64()             lseek64()
lstat64()             mmap64()
nftw64()              open64()
readdir64()           setrlimit64()
stat64()              statvfs64()
truncate64()

	In our case, they can basically be wrappers for the existing
	functions.  The *64 functions take 'off64_t' instead of 'off_t'
	parameters, which in our case are also the same size.

	This is purely a compatibility issue, I wouldn't suggest encouraging
	the use of these API's inside NetBSD userland programs.

>How-To-Repeat:
	nm /usr/lib/libc.a | fgrep lseek64

>Fix:
	No fix as yet.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Tue, 12 Jul 2016 02:45:53 +0000
State-Changed-Why:
WONTFIX. Compiling on NetBSD (or on 4.4, for that matter) is the same as
compiling with -D_FILE_OFFSET_BITS=64 in that scheme, which is what
everyone should be doing anyway.
The open64() drivel should never have existed in the first place.


>Unformatted:

Home	PR Database Search