Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.vbc.net!vbcnet-west!garlic.com!uunet!in2.uu.net!204.178.176.27!hunter.premier.net!news.mathworks.com!newsgate.duke.edu!hal.cs.duke.edu!cs.duke.edu!trt
From: trt@cs.duke.edu (Thomas R. Truscott)
Newsgroups: comp.unix.solaris,comp.unix.bsd.misc,comp.unix.internals
Subject: Re: Solaris 2.6
Date: 6 Dec 1996 22:36:04 GMT
Organization: SAS Institute Inc.
Lines: 40
Distribution: inet
Message-ID: <58a74k$4j2@hal.cs.duke.edu>
References: <32986299.AC7@mail.esrin.esa.it> <casper.32a40b7b@mail.fwi.uva.nl> <587jrv$9rf@news.parc.xerox.com> <587meg$h67@web.nmti.com>
NNTP-Posting-Host: juliet.cs.duke.edu
Xref: euryale.cc.adfa.oz.au comp.unix.solaris:91651 comp.unix.bsd.misc:1708 comp.unix.internals:11489
I am late to this discussion, but let me now say:
IT WAS THE INDEPENDENT SOFTWARE VENDORS WHO FOISTED
THE LARGE FILE SPEC ON YOU, NOT SUN!!!
Indeed SunSoft fought the good fight against the ISV tyranny. See:
http://www.sas.com/standards/large.file/hmail/0066.html
But the ISVs refused to budge. For example see:
http://www.sas.com/standards/large.file/hmail/0068.html
================================
[I don't have much to add to the comments by Casper Dik and others, but ...]
>The Sun approach requires a #define to indicate you want to use the *new*
>versions of the header files to link with 64-bit libraries.
So the debate is about what the default should be?
I suppose it would be nice if the default were "large file API"
and heck let's add in "-mt" but obviously this would result in
more breakage of existing source code than would the Sun approach.
There has been mention of SCO and "Expanded Fundamental Types".
What they (USL) did was put static functions in /usr/include/sys/stat.h
for stat/fstat/lstat/mknod which called appropriate underlying functions.
For example programs compiled to use the "new" stat() call
would end up calling _xstat().
Other than the unusual stack backtrace this works fairly well.
Except that if you compile a program with 100 .c files
you can end up with a binary containing 400 unused static functions.
Using this method for the large file API is less attractive
because the large file API has lot more functions.
In my opinion the Solaris "#pragma redefine_extname stat stat64"
is a much simpler way to handle this type of problem.
Tom Truscott