Re: Re3: coreutils v5.2.1 - stat.c

[Paul Eggert]

ThMO <address@hidden> writes:

>> > · 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...

Then you'll need to have an up-to-date Bison.  Bison 2.1 is the
current stable version.  The general rule with coreutils (as with many
other GNU packages) is that if you want act like a maintainer, you
need the latest stable maintainer's tools.  If you merely want to
compile and install, then the rules are relaxed and the code is
buildable with a much wider variety of tools.

> 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.

Please report any compatibility issues to <address@hidden>.  In the
meantime you can install both versions of Bison in different
locations, and use Bison 2.1 when building GNU software from scratch.

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

Sorry, I should have been clearer.

By "patch" I meant the output of "diff -pu" for all the files you
changed, along with ChangeLog entries appropriate for each file.  We
should be able to take the existing source code, apply your patch by
using "patch -p0", and then do a "make check" and everything should
work just fine.  You can see an example patch here:
<http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00202.html>.

Typically the hardest part of writing a patch is the documentation.
Then the test cases.  The source code is the easiest.

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

The output always omits "1".  This is longstanding tradition: I
wouldn't want to change it.

"factor" should probably diagnose any attempts to factor 0, since
it's not consistent that 0 and 1 have the same reported factors.
Solaris 10 "factor" (which uses a different output format) exits
if you try to factor 0.

> IMHO it's an important user-visible bugfix,

Thanks.  It's in NEWS now.

> Even though sdd is slow too in this case, it's faster than dd.

Can you use the strace command to characterize why that would be?
What is sdd doing that makes it run so much faster on your host?
(I'm afraid you'll have to help us out here, as we don't have your
hardware.)

> 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.

Can't you do something like this?

  (# Do the initial seek
   dd bs=1 count=0 seek=37 &&

   # Copy files in larger chunks
   dd bs=8192 count=100000)  <input >output

(of course substituting your own values for 37, 8192, and 100000).

> 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...

POSIX says that "<<", ">>", and "?" must be treated as valid string
operands, and that ":" is an infix operator meaning string matching,
so it'd be tricky to add these without violating POSIX.  For example
"expr '?' : '>>'" must output "0".  I suspect that ?: would run afoul
of :.  I suspect "<<" and ">>" could be done (as well as ~, ^, !), but
it'd have to be checked carefully for compatibility.

Maybe ?: could be added under a different syntax (along with | and &,
presumably), under the same rules as << etc., but the different
spellings would be confusing.

Given all these hassles, I think it's better to ask people to use
$((...)), as that's more portable (it's been standardized as part of
POSIX) than extensions to expr would be.  expr really is for backwards
compatibility only.