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 From: "Peter J. Farley III" Subject: Re: Why are we using offset_t and not off64_t? Cc: djgpp-workers AT delorie DOT com In-Reply-To: References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001209125228 DOT 025cbec0 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Precedence: bulk At 09:41 AM 12/10/00 +0200, Eli Zaretskii wrote: >On Sat, 9 Dec 2000, Peter J. Farley III wrote: >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)