[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] Huge files on Win32

From: Thomas Dickey
Subject: Re: [Lynx-dev] Huge files on Win32
Date: Sat, 10 Jan 2015 18:11:01 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Jan 09, 2015 at 11:34:38AM +0000, Gisle Vanem wrote:
> Thomas Dickey wrote:
> >MinGW in that area is just plain broken.
> MingW *can* use >4 GB 'st_size' from stat() just fine in other
> programs. E.g. curl + Wget.
> >You probably can't get that with 32-bit MSVC.
> MSVC v16 (32-bit too). I think the problem is in StrAllocVsprintf()
> (via HTSprintf0). It doesn't understand formats such as 'I64d'.
> But the code around this so messy I don't know what to do about it.

HTSprintf0 has two flavors: lynx's interpreter and the runtime, if that
happens to support vasprintf.  Since that function isn't standard, it's
not in MSVC.

Since MingW lost its "minimum" state a while back, and started porting
chunks of GNU stuff for its runtime, one might assume it supports vasprintf.
It's more complicated than that: I investigated a compiler warning in
this area a while back and found that it was due to cross-compiling,
with MinGW's header files redefining the printing format and types I used in
Lynx to make off_t-related code work with different types.

(MinGW-64 is different, of course)

> In HTFile.c I have asserted that 'off_t' really is 64-bits.
> So in:
> static char *FormatSize(char **bufp,
>                       char *start,
>                       off_t entry)
> {
>     char fmt[512];
>     if (*start) {
>       sprintf(fmt, "%%%.*s" PRI_off_t, (int) sizeof(fmt) - 3, start);
>       HTSprintf0(bufp, fmt, entry);
>     } else {
>       sprintf(fmt, "%" PRI_off_t, CAST_off_t (entry));
> On Win32, what should 'fmt' become for HTSprintf0() to do it right?
> Since "%I64d" is not supported, should PRI_OFF_t be forced to "lld"
> on Windows too?

That sounds as if it could work:

HTSprintf0 would need a bit of logic to count the "l" characters to
see that it's doubled.  (Linux accepts the same "%lld", it seems, so
there's a way to develop/test it without much fuss).

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]