James Vega wrote:
> Since Vim can now open “largefiles” on 32-bit systems, there are some
> changes necessary to properly store/access the size of those files.
> This is easy to see as when you open a largefile, the status message
> showing the number of lines and characters in the file will have a
> negative number of characters for largefiles since the 32-bit long was
> overflowed.
>
> The attached patch (generated against 7d3cf4693a8f) changes the relevant
> buffer size pieces of the code to use off_t instead of long.
> Unfortunately, there isn't a standard way to format off_t for
> printf-style functions, so that required some preprocessor checks for
> what to use. There may be a better way to do that, but it worked for
> me.
>
> I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
> and 64-bit environments).
Hi James
This chunk...
@@ -5062,7 +5062,7 @@
if (nchars == 1)
STRCPY(p, _("1 character"));
else
- sprintf((char *)p, _("%ld characters"), nchars);
+ sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
}
}
Changes the translated string in src/po/??.po files from:
#, c-format
msgid "%ld characters"
... into:
#, c-format
msgid " characters"
Notice that the %ld has disappeared in the po file. Isn't it an issue?
Perhaps we should do it the less elegant way:
if (nchars == 1)
STRCPY(p, _("1 character"));
else
/* Can't use PRINTF_OFF_T here without confusing gettext */
#if defined(SIZEOF_OFF_T) && (SIZEOF_OFF_T > SIZEOF_LONG)
sprintf((char *)p, _("%lld characters"), nchars);
#else
sprintf((char *)p, _("%ld characters"), nchars);
#endif
-- Dominique
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
