From: Greg Troxel <gdt@ir.bbn.com>
Subject: Re: largefile64 on ports
Date: Sat, 09 Sep 2006 19:59:33 -0400 [thread overview]
Message-ID: <rmik64ca8wq.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <873bb2x8sp.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 09 Sep 2006 09:01:10 +1000")
[-- Attachment #1.1: Type: text/plain, Size: 1650 bytes --]
I see your points, but it still seems really gross to impose the two
sets of calls, esp. in 2006 when the transitional API should have been
transitioned already (with simply having 64-bit off_t all the time,
and ABI compat for old programs via syscall renumbering).
I think it's important that systems with native 64-bit off_t programs
still work and don't need to do anything special. I suppose the foo64
calls will just be the same as the regular calls, and guile can
somehow default to that. So guile-using programs that are aware of
the foo64 method slots and those that don't should both work,
including for files of >32 bit size. I think your patch does that;
if there are no foo64 syscalls then foo is used, and with off_t, so
things should be fine. Am I following correctly?
> I see in ports.c that _LARGEFILE64_SOURCE is defined. As far as I can
> tell, this is a glib thing rather than a standard thing and thus
> should be ifdefed.
Should do nothing anywhere it's unrecognised or unsupported.
Probably, but still this is namespace pollution at best.
_LARGEFILE64_SOURCE doesn't show up in the SUS document you referred
me to. (Thanks for the link; I didn't know about this before. I
think 4.4BSD chose to just make off_t 64-bit and skip the transitional
API. In retrospect that was clearly the right move - all this pain is
simply skipped, and old programs run fine. But I realize that's not
the question on the table.) So IMHO a configure test is in order for
this. But it's not a big deal.
I don't mean to sound super cranky - thanks for making guile better.
gdt, guile-devel standards/portability crank
[-- Attachment #1.2: Type: application/pgp-signature, Size: 185 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2006-09-09 23:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-07 23:17 largefile64 on ports Kevin Ryde
2006-09-08 13:25 ` Greg Troxel
2006-09-08 23:01 ` Kevin Ryde
2006-09-09 23:59 ` Greg Troxel [this message]
2006-09-11 0:43 ` Kevin Ryde
2006-09-08 15:13 ` Andy Wingo
2006-09-26 1:51 ` Kevin Ryde
2006-09-26 7:52 ` Ludovic Courtès
2006-09-26 22:21 ` Kevin Ryde
2006-09-27 8:27 ` Ludovic Courtès
2006-09-28 0:27 ` Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rmik64ca8wq.fsf@fnord.ir.bbn.com \
--to=gdt@ir.bbn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).