Message-Id:	<5.0.2.1.0.20001210173342.025c2930@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 5.0.2
Date:	Sun, 10 Dec 2000 17:41:44 -0500
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: Why are we using offset_t and not off64_t?
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.1001210093927.700K-100000@is>
References:	<5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001209125228 DOT 025cbec0 AT pop5 DOT banet DOT net>
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

At 09:41 AM 12/10/00 +0200, Eli Zaretskii wrote:
 >On Sat, 9 Dec 2000, Peter J. Farley III wrote:
<Snipped>
 >Whatever the reasons are, we could typedef off64_t to be the same as
 >offset_t.

OK, I could see that.  But see more below.

 >> Why not just lift the __USE_LARGEFILE64 and
 >> __USE_FILE_OFFSET64 code from glibc's posix/sys/types.h, suitably
 >> modified for DJGPP?
 >
 >What do you need these __USE_* symbols for?

Only to get the "standard" (such as they are) typedef set, so that 
porting is easier.  They are of no use on their own.

 >I'd advise against using symbols we don't need, because some 
configure
 >script might test for them and draw wrong conclusions.

THAT I must agree with.  It is an excellent reason *not* to use them, 
since I know for a fact that perl, inter alia, tests them to determine 
large file support.  At the least, we should probably not use them 
until or unless we manage to have "real" large-file support.

I will just let that sleeping dog lie, and use the current offset_t 
definition.

Thanks for the info and advice.

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -