bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: about gawk |& operator and getline on HPUX11


From: Stepan Kasal
Subject: Re: about gawk |& operator and getline on HPUX11
Date: Sat, 25 May 2002 18:02:46 +0200
User-agent: Mutt/1.2.5.1i

Hallo,
        thank you for your comments.

On Fri, May 24, 2002 at 10:53:19AM -0700, Paul Eggert wrote:
> > From: Stepan Kasal <address@hidden>
> 
> > -#define DEFBLKSIZE (stb->st_blksize ? stb->st_blksize : BUFSIZ)
> > +                   /*
> > +                    * 100k must be enough for everybody,
> > +                    * bigger number means probably a bug in fstat()
> > +                    */
> > +#define MAXBLKSIZE 102400
> > +#define DEFBLKSIZE (stb->st_blksize > 0 && stb->st_blksize <= MAXBLKSIZE \
> 
> It is reasonable to check that st_blksize is positive, but I'm not
> sure that it is a good idea to put an arbitrary limit on it.  GNU
> software shouldn't have arbitrary limits.

This arbitrary limit only meant that the default 1K buf is used instead, as on
platforms where st_blksize is not available.  But anyway, I agree, it's bad.

> What exactly is the bug that ARPA Transport patch PHNE_26771 fixes?
> Is this a bug in the runtime library, or a bug in the headers?  Is
> there a reliable way to detect whether the bug exists, preferably at
> compile-time?  If we can find out what it is, then we should be able
> to write a test that detects it.

The documentation, as far as I know, tells us only what Zhao Xiang has already
posted to gnu.utils.bug:

        Customer's application gets the wrong value from fstat().
        Resolution:
        The value returned via st_blksize is now retrieved
        from the same info as in 10.20.

So it seems that the runtime lib or even kernel takes a value from a bad place.
>From that docs, we can suppose that any value is possible.  Thus I tried to
check for insane values.
In the particular case the original bug report described, the value was
negative.

So for now, the official tree will probably have only the test for negative
value (the patch is attached to this mail).

> Wouldn't it be better to fix Autoconf's AC_STRUCT_ST_BLKSIZE so that
> it reports that st_blksize does not exist on the buggy platforms?

1) Yes, that would be nice.  I'll do this, eventually, and ask Zhao Xiang
to test it.  (Or, if you, Zhao Xiang, have plenty of free time and want to
spend it with this work, just write two small programs which can be run in
parallel and which connect on an arbitrary port, so that one of them can
issue fstat() and look whether the result is negative.  Perhaps even simpler
fstat() calls are broken, just unix socket or simple fstat on file.
-- I can then provide the wrap up for autoconf and submit it as patch to
autoconf and to gawk, in case you don't want to submit the results of your
work yourself.)

2) But I have a question about autoconf 2.53a, the last version available on
alpha.gnu.org.  (I know gawk currently uses an older version, so the test
will be perhaps copied twice: one copy for gawk tree and one for autoconf).

AC_STRUCT_ST_BLKSIZE is obsolete, one should use
AC_CHECK_MEMBERS([struct stat.st_blksize]) instead.
But that generic macro cannot contain that special test for HP-UX 11.
We need "specialization"--I've seen some words about it in autoconf's
TODO but what is its actual status?  Is it just a wish?

Thank in advance for any advice or help
(from any of the receivers of this mail),
                Stepan Kasal



reply via email to

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