Re: [PATCH 21.5] Large file support
On Tue, Mar 5, 2013 at 1:20 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
"When possible" doesn't seem like the right thing to
do, at least if
that's defined by "compiler supports a 64-bit integer type." But
AFAICS what the patch actually does anyway is use off_t where
available, which seems to be TRT. Right?
Sorry, what I meant by "when possible" is "when the C library knows
what _FILE_OFFSET_BITS is and handles it as defined by POSIX".
Is there any harm in allowing bignums in *all* fields? It seems to
me
that on most installations we'll never see bignums, so there's no
space penalty. And since we need to check numerical type anyway for
any numerical manipulation (including comparison -- they might be
floats), there should be no performance penalty period.
No harm. You're right, the uid and gid fields may also overflow a
Lisp integer. I'll make that change.
What happens if off_t isn't supported by the system? (See
definition
of OFF_T macro below.)
Then configure defines it to be "long int". This is part of the
expansion of AC_TYPE_OFF_T (line 2643 of configure.ac), which is
before the added AC_CHECK_SIZEOF(off_t) on line 2727.
> diff -r 1af0602ff9a2 lib-src/insert-data-in-exec.c
> ＠＠ -55,8 +56,8 ＠＠
> {
> FILE *te, *xe, *dump;
> unsigned char *xed, *p;
> - long size, size_dump, size1, i;
> - long max_size, offset;
> + size_t size1, offset;
> + OFF_T size, size_dump, max_size, i;
Why would these be off_t and not size_t? Just because they're being
added to a ptr_t doesn't seem right. AFAICS they don't get passed to
FSEEK or compared to the value of FTELL.
Let's see ... size and size_dump are assigned the return value of
FTELL(), which might really be ftello(), so an off_t. Of course, both
are passed to read(), where they need to be size_t, as well as
compared to size1, which is a size_t. So we could make them size_t,
if you prefer. We should really check that the return value of
FTELL() is not -1; if it isn't, then casting it to a size_t is fine.
max_size is OFF_T only because it is compared to size_dump, so if we
change size_dump to size_t, then max_size should change, too.
Finally, i is compared to an expression involving size. So I really
have no objection to changing them to size_t. Check the attached
patch, where I've done just that.
Doncha just *love* C?
http://www.netfunny.com/rhf/jokes/90q2/ode.html
Need I say more?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches
Attachments:
- xemacs-stat64-v2.patch (application/octet-stream — 7.8 KB)