Re: largefile64 on ports

[Greg Troxel]

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

pgp1WOlImD7RK.pgp
Description: PGP signature