Re: largefile64 on ports

[Kevin Ryde]

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
hold-out.

> 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
> bits.

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

        http://www.unix.org/version2/whatsnew/lfs20mar.html

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,
> etc.

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
> empty.

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
> ones.
> ...
> Yes, people have to rebuild, and they'll have to change their source
> slightly,

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
controversial.