bug-gzip
[Top][All Lists]
Advanced

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

RE: gzip > 1.3.? broken on NSK


From: Matthew Woehlke
Subject: RE: gzip > 1.3.? broken on NSK
Date: Mon, 11 Dec 2006 09:51:55 -0800

Paul Eggert wrote:
> Matthew Woehlke writes:
>> gzip is using 64k in file_read (zip.c), but SSIZE_MAX is 53248 (52k).
>
> Wow, that's a new one.
>
>> We could
>> limit the size to SSIZE_MAX, but I don't know how portable that is.
>
> It's portable if you check that SSIZE_MAX is defined first.
> Something like this:
>
> #  if defined SSIZE_MAX && SSIZE_MAX < INBUFSIZ
> #    undef INBUFSIZ
> #    define INBUFSIZ SSIZE_MAX
> #  endif

I'm not sure where you put that, but if it fixes trying to read 64k at
once, then it should work.

> This should be good enough for OSF, whose maximum size is far greater
> than INBUFSIZ.
>> Alternatively, on all platforms I looked at, _POSIX_C_SOURCE (both 
>> existed, and) was 32k, so using that as a fixed value is probably OK 
>> (and obviously is no *less* safe than the current behavior).
>
> Sorry, I don't follow this; what does _POSIX_C_SOURCE have to do with
> it?

Sorry, I meant to write _POSIX_SSIZE_MAX (which may not be defined
unless _POSIX_C_SOURCE is defined).

> I installed the following; this should fix all the NSK bugs you
> reported. Can you please try it?
> [patch snipped]

Hmm, either that didn't work, or didn't make it into 1.3.8; I still get
'Invalid argument' when trying to compress (but the build was clean, so
my other gripes must have all made it in). I still I'll try to figure
out what is still going wrong later today. Checking quickly, I do see
that file_read is still trying to read 64k.

FYI: the solution I used to get 1.3.7 working was to check in file_read
if 'size' is too big, i.e. read the smaller of 'size' and 'SSIZE_MAX'.
It would be easy to do something like:

#ifdef SSIZE_MAX
  if (size > SSIZE_MAX)
    size = SSIZE_MAX;
#endif

...which seems to work. I think this is OK because file_read is not
required to return 'size' bytes, and returning fewer bytes may not be
assumed to mean EOF (since this would be a normal occurrence when
reading from a pipe).

Actually, my current fix is even more paranoid, and caps at 32k if
SIZE_MAX is not defined (due to the aforementioned _POSIX_SSIZE_MAX
which seems to be 32k everywhere I checked).

-- 
Matthew




reply via email to

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