Re3: coreutils v5.2.1 - stat.c

[ThMO]

Hello Paul, Bob and others listening,

> > · even though the C compiler might be able to deal with 64-bit integer 
> > values,
> >   this must *not* be the case with the C pre-processor:
> >
> >   #define ULLONG_MAX 18446744073709551615ULL
> >
> >   the C compiler (gcc v2.7.2.1) *is* able to deal with that value, but the
> >   cpp can't
> 
> Ouch.  Thanks for reporting the problem; this is due, I think, to a
> change installed in January.  Can you please try the following private
> snapshot instead?
> 
> http://www.cs.ucla.edu/~eggert/coreutils-5.3.1-20050928-eggert.tar.gz

THX, I've downloaded it during the past 40 minutes and tried it out.
Your fix solves this specific problem without further patching.
But there's a new problem, although it falls into the same category, inside
file lib/gethrxtime.c at line 70: the header file xtime.h defines:
  # if HAVE_LONG_LONG
  typedef long long int xtime_t;
  #  define XTIME_PRECISION 1000000000LL
  # else
  ...
  #endif
Again cpp groks about the `LL' modifier.

---

> > · lib/getdate.y:
> >   I'm using bison v1.28 - and for me it's unacceptable, that this grammar
> >   can't be processed corrrectly with this older version,
> 
> You shouldn't need to process it at all, since getdate.c is present in
> the source distribution.  Perhaps the time stamps on your files were
> corrupted?

No, I always reproduce every generated files...

> >   it should also be processed by stock berkeley yacc
> 
> But that wouldn't support reentrant parsers.  getdate needs to be
> reentrant, for other projects.  It should not be a problem anyway;
> you shouldn't need to run either Bison or Yacc.

O.K., reentrancy is an argument, but IMHO v1.28 does support pure parsers,
although it might not be stated inside the info-pages.
The specific point I meant was the directives %parse-param and %lex-param.
This older version doesn't know about those directives, although there are
defines for declaring them a little bit different, e.g. YYPARSE_PARAM and
YYLEX_PARAM, if I remember it right - but you should know better, as I now
know, where I heard your name from, as you're hacking on bison too.

> >   BTW, is anyone able to guarantee me, that bison v2.0 has not even one
> >   problem with processing older (and oldest - I'm using software packages
> >   dated in the early 80's) grammar files?
> 
> Someone could guarantee you that, yes, if you paid them enough.  :-)

Yeah. :-)
In the meanwhile I tried out bison v2.1, but wasn't successful with some
grammar files, where I had to stuff together three SQL-select parsers using
one flex-scanner and therefore had to, maybe misuse the C pre-processor, so
I'll stick to my old version locally.

> > · --disable-nls:
> >   IMHO there is no need, if I decide to configure *wihtout* NLS support,
> >   which I usually do, to setup a specific locale,
> 
> --disable-nls affects only diagnostics and the like: it does not
> disable all usages of locales.  For example, LC_CTYPE still affects
> whether something is considered to be a letter.

Alright, so I am definitely wrong here.

> >   the man-page should *always* reflect the various options, for which a
> >   command was configured for
> 
> The dd man page has changed in the latest CVS version; perhaps the
> point is moot now.  To be honest I didn't fully follow your comments.
> "info coreutils dd" works on my host and that is what the man page suggests.

All pre-processed man-pages refer to the info-pages as: info <cmd>, but that
should be named: info coreutils <cmd>.
To fix this problem for *all* man-pages inside the coreutils package you
should extent the specific rule somewhat:

# snipped from man/Makefile
.x.1:
        @rm -f $@
        @echo "Updating man page $@";           \
        mkdir $t;                               \
        (cd $t && $(LN_S) ../../src/$(mapped_name) $*); \
        $(PERL) -- $(srcdir)/help2man           \
            --include=$(srcdir)/$*.x            \
            --output=$t/$@ $t/$*        \
  --info-page="coreutils $*"
        @sed 's|$*\.td/||g' $t/$@ > $@
        @chmod a-w $@
        @rm -rf $t

The neccessary parameter is:  --info-page="coreutils $*"
That way the man-page clearly state the command to type as:
  info coreutils <cmd>
without the need to name each command inside the info/dir file explicitely.
E.g.: my info entry looks like this:
  * Coreutils: (coreutils).     Core GNU utilities (v5.2.1).
But there is *no* entry like that:
  * dd: (coreutils)dd invocation.               Copy and convert a file.
Typing `info dd' results in an error message, that info can't find an entry
for `dd', but calling it `info coreutils dd' info knows to open the coreutils
info file and looking up the dd command there, which succeeds.

> > · factor:
> >   it's increddible - your factor command is *not* able to factorize negative
> >   values
> 
> Patches would we welcome here.

#include <limits.h>
void
factor( signed int  num, ...)
{
  switch ( num)
    {
      case 0:
        printf( "0:\n");
        return ;
      case 1:  case -1:
        printf( "%d: %d\n", num, num);
        return ;
      case INT_MIN:
        printf( "%d: -1 2 ", num);      /* INT_MIN is *always* even */
        num= 1 << ( sizeof( num)* CHAR_BIT- 2);
        break;
      default:
        printf( "%d: ", num);
        if ( num < 0)
          {
             printf( "-1 ");
             num= -num;
          }
        break;
    }
  /* factorize as usual */
  ...
}

BTW, wouldn't it be correct to write
  1: 1
instead of
  1:
as 1 can be factorized by itself?

> > · NEWS:
> >   why is the above bug, which I reported, *not* listed within the NEWS file,
> >   clearly stated as a fixed bug?
> 
> NEWS reports only important user-visible fixes.  I don't know which
> bug you meant by "the above bug".  If we forgot to put a bugfix in
> NEWS and it's important please tell it what it was.

IMHO it's an important user-visible bugfix, if the stat command doesn't state
success if it fails to stat a file, e.g. I found this problem while extending
my shell-script for burning CD's and I had to check the size for pre-built
ISO-images instead of creating them on the fly:

  fsize="`stat -c '%s' \"$fname\"`" || fail "unable to stat file \´$fname'"

But as the stat command delivers success the value of fsize is not a number,
so I had to work around this problem by prepending:

  [ ! -e "$fname" ] && fail "unable to stat \`$fname'"
  fsize="`stat -c '%s' \"$fname\"`"

But even here there is a chance, that the stat command may fail - so I'm sure
you'll see the user-visiblity of this specific bugfix now?

> > · performance of the dd command:
> >   the execution speed of dd sucks heavily,
> 
> Can you give a specific example of the problem?  A shell transcript
> would help.

#!/bin/bash -f
# mstart -> mend == msize
mstart=70628
mend=57910964
msize=$[ $mend- $mstart]
fname=The-Chubb-Chubbs.352x288.mpeg.avi
echo "dd bs=1c count=$mstart if=$fname of=z.0"
dd bs=1c count=$mstart if=$fname of=z.0
echo "dd bs=1c skip=$mend if=$fname of=z.N"
dd bs=1c skip=$mend if=$fname of=z.N
# dd:  2:45 minutes (v5.2.1)
# dd:  2:50 minutes (v5.3.0)
echo "dd ibs=1c obs=32k skip=$mstart count=$msize if=$fname of=z.mpeg"
dd ibs=1c obs=32k skip=$mstart count=$msize if=$fname of=z.mpeg
# sdd: 1:03 minutes
echo "sdd ibs=1 obs=32k iseek=$mstart count=$msize if=$fname of=z.mpeg"
sdd ibs=1 obs=32k iseek=$mstart count=$msize if=$fname of=z.mpeg

The above file is an award winning short movie in 2003 taken from Sony's
home-page, although I don't know the actual link anymore - sorry for that.
The offsets are only true for the german version of this movie.
The AVI file is in CD-XA format and the task is to extract the mpeg movie
stream out of this container.
Even though sdd is slow too in this case, it's faster than dd.
To give you a clue - a quick and dirty C hack needs less than 4 seconds
to extract the 57 MB mpeg stream (the last dd invocation), working with
32 kB buffers (this size performs best for my old SCSI drives).
At least for me there are several tasks, where I need to extract some
portions out of the middle of some bigger file and especially in this case
dd (and even sdd) is very slow, as there is no other way - at least I see
no combination of options, which does the same - to perform this task with
dd.  The time-consuming task for dd is, that the input stream will be fetched
one byte at a time, although it could be fetched in larger chunks, after the
initial seek into file (if it's seekable, of course) has been done.
A solution might be to classify the input stream in order to detect, if it's
a special device, where it must be fetched one byte at a time, and otherwise
larger chunks could be read to speed this common case up?

> Thanks again for your comments.  (Though we don't really need to know
> about your sex life....)

Yeah I know... ;-)
But it's my way to tell people, that there are many other pleasurable things
to me like re-compling my complete system again and again...
I'm sure you know exactly, what I want to say.

BTW, before I forget - I'd like to suggest an extention to the expr command:
it would be nice, if expr could handle the C shifting operators `<<' and `>>'
as well as the ternary opertor `? :'...
But there might be a chance, that POSIX says something different...

THX for listening.

CU Tom.
(Thomas M.Ott)
Germany