[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: largefile64 on ports
Re: largefile64 on ports
Sat, 09 Sep 2006 09:01:10 +1000
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Greg Troxel <address@hidden> writes:
> Is there any good reason to just not use the 64-bit calls all the time
> if they exist?
I did that for file descriptors and filenames, the ports are the
> What does Solaris do? I looked on the web and couldn't figure out if
> one has to use different calls or if they've just changed off_t to 64
glibc has kept off_t at 32-bits, I suspect solaris is the same
(without being much worried about that system).
> Is _LARGEFILE64 a glibc/Linux thing, or is it broader than that? Are
> there any relevant standards?
The single-unix spec
Perhaps netbsd has made that transition the default system-wide
("#define _LARGEFILE_SOURCE" in essense).
> because it's reasonable for systems to just have 64-bit off_t (and
> I'd argue preferable; Solaris and glibc docs seem to agree), the
> whole mess of having separate system calls should not be exported to
> guile users.
Exporting the 64-bit would be a bonus, letting applications on gnu
systems do 64-bit files the same as guile (will).
> So, I'd say that via configure one should find the large calls if they
> exist, and #define open_large to them, or to open if not present,
Yep, I did that for the simple bits. "open_or_open64" and friends
are, as their names suggest, the one or the other function according
to what's available.
> But now I realize the point is about the C interface labeled SCM_, and
> I see why this is much harder.
Yep, the problem is that mucking about with off_t breaks source and
binary compatibility in the port type descriptor structure seek and
truncate function fields. If those two weren't exposed, or if they
were size_t or something, then it would have been as easy as flicking
the _LARGEFILE_SOURCE switch, as intended for most applications.
> 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.
> I don't follow SCM_HAVE_LARGEFILE64; grepping for it in CVS comes up
To be added in a configure test. Another name like SCM_HAVE_OFF64_T
would be a possibility, it'd be in the public scmconfig.h.
> Perhaps we can define scm_off_t as uint64_t, and just have scm_foo
> calls that use that only 64 bits. Or both, and deprecate the old
> Yes, people have to rebuild, and they'll have to change their source
That's what I'd like to avoid. I think asking for source changes in
application code should be a last resort. I'd probably prefer just to
make some internal changes for now if exposing the 64-bit funcs is too