[Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows

[noreply@sourceforge.net]

Patch #101773 has been updated. 

Project: 
Category: Build
Status: Open
Summary: BeOS PPC lacks fseeko, but isn't MS Windows

Follow-Ups:

Date: 2000-Oct-04 11:18
By: tmick

Comment:
This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470)

The problem:
  NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks.

Question:
  What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS?

Right Answer (tm):
  If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS.

I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is.

It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then?
-------------------------------------------------------

Date: 2000-Oct-06 09:22
By: fdrake

Comment:
I've asked Donn to respond to Trent's comments; waiting for a response before taking further action on this patch.
-------------------------------------------------------

Date: 2000-Oct-06 11:04
By: donnc

Comment:
Dang, I seem to have missed this wonderful SF gimmick by
answering my email correspondence by email.  Here is the
last message I sent to tmick:

Date: Wed, 4 Oct 2000 17:08:52 -0700 (PDT)
From: Donn Cave <donn@u.washington.edu>
To: patches@python.org
Subject: Re: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't
 MS Windows
In-Reply-To: <20001004134610.D1657@ActiveState.com>
Message-ID: <Pine.A41.4.21.0010041644080.60090-100000@homer38.u.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

| Yes, again, you are right that that would be complex. If _fseek is equivalent
| to fseeko then it should follow the same path through the code as fseeko.
| Maybe then #define a FSEEKO, something like
|
| #ifdef __BEOS__
|     /* can this be made to specify the BeOS PPC branch specifically? */
|     #define FSEEKO _fseek
| #else
|     #define FSEEKO fseeko
| #endif
|
| Would you be able to try that?

It will work.  The platform would be

  #if defined(__BEOS__) && defined(__MWERKS__)
        (use _fseek())

If you like, you can even use fseeko:

  #if !defined(HAVE_FSEEKO) && defined(__BEOS__)
  #    define fseeko _fseek
  #    define HAVE_FSEEKO 1
  #endif

Incidentally, after some tests, I am more inclined to think BeOS
does support these functions in a meaningful way.  We don't have
"holes", so I can't write at 64 bit locations in any file, but I
do get "No space left on device", and I take that as evidence
that they're not just ignoring the high bits of the parameter.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470