Hello Matt,
* Matt Rice wrote on Tue, Sep 14, 2010 at 06:22:35AM CEST:
> I noticed that autotools when running 'make dist' rely on subdirs
> implementing a distdir target
> which wasn't documented in the gnu coding standards, before making an
> attempt at documenting it
> I figured i'd ask if it i
I noticed that autotools when running 'make dist' rely on subdirs
implementing a distdir target
which wasn't documented in the gnu coding standards, before making an
attempt at documenting it
I figured i'd ask if it is something that should be added?
Eric Blake writes:
> Would anyone object if I removed most (if not all) 95 instances of my
> name from those files, given the argument that 'git shortlog file'
> will still give a pretty good indication of who the original author
> was?
I support this. The only reason I've been putting my name
On Mon, Sep 13, 2010 at 2:23 PM, Eric Blake wrote:
> Ralf just pointed this out to me:
> http://producingoss.com/en/producingoss.html#territoriality
>
> For an example of something that looks like territoriality, notice how many
> tests/test-*.c files are attached to my name:
>
> $ git grep 'Eric
I audited fts, getcwd, and glob for the possibility of dirfd returning
-1, and propose the following patch to fix all the problems I saw.
* For fts, rewrite to avoid dirfd entirely. This is doable now that
the fdopendir replacement doesn't close its argument. The trick is
to never invoke ope
Bruno, this one probably needs your help for a gnulib workaround. On
MirBSD 10 (20100815), wcrtomb is found but not replaced; leading to
failure in the unit test:
ac_cv_func_wcrtomb=yes
ac_cv_have_decl_wcrtomb=yes
gl_cv_func_wcrtomb_retval=yes
gl_cv_have_raw_decl_wcrtomb=yes
GNULIB_WCRTOMB='1'
Ralf just pointed this out to me:
http://producingoss.com/en/producingoss.html#territoriality
For an example of something that looks like territoriality, notice how
many tests/test-*.c files are attached to my name:
$ git grep 'Eric Blake' tests |wc
95 7626817
Would anyone object
* m4/float_h.m4 (gl_FLOAT_H): MirBSD copied OpenBSD's bug.
* doc/posix-headers/float.texi (float.h): Document it.
Signed-off-by: Eric Blake
---
The fix turned out to be rather trivial, given that OpenBSD has the
same bug. Honestly, sometimes I wonder how much standards-compliance
testing any of
On 09/13/2010 02:08 PM, Eric Blake wrote:
Bruno, what else do you need to help debug this? It's crashing on an
i686 installation of the most recent MirBSD (version 10, 20100815),
using mgcc 3.4.6 (propolice; gpc; MirOS 0AAB). I don't yet know whether
to suspect a compiler error, a buggy , or fau
Bruno, what else do you need to help debug this? It's crashing on an
i686 installation of the most recent MirBSD (version 10, 20100815),
using mgcc 3.4.6 (propolice; gpc; MirOS 0AAB). I don't yet know whether
to suspect a compiler error, a buggy , or faulty configure
results; but this failure
On 09/13/10 12:20, Jim Meyering wrote:
> That passes all tests on Fedora 13 and looks sensible.
> Thanks for the fix!
Your welcome. I pushed it with a ChangeLog message
that points to this thread.
This follows up on the thread earlier today. In testing my earlier
patch, I found that fdopendir (FD) didn't do the right thing when
FD was the maximum allowed file descriptor but lower-numbered file
descriptors were available: it failed with errno == EMFILE. I pushed
the following patch instead,
Paul Eggert wrote:
> On 09/13/10 01:02, Jim Meyering wrote:
>> I ran this test: apply your patch, compile everything and
>> run coreutils' "make check" tests. With this change, 4 tests fail:
>>
>> $ grep FAIL tests/test-suite.log
>> FAIL: chgrp/posix-H (exit: 1)
>> FAIL: chgrp/recurse
On 09/13/10 01:02, Jim Meyering wrote:
> I ran this test: apply your patch, compile everything and
> run coreutils' "make check" tests. With this change, 4 tests fail:
>
> $ grep FAIL tests/test-suite.log
> FAIL: chgrp/posix-H (exit: 1)
> FAIL: chgrp/recurse (exit: 1)
> FAIL: du/
[Adding bug-tar.]
On 09/13/10 03:52, Jim Meyering wrote:
> He means merely that when tar traverses a tree of depth N
> it will no longer require N open file descriptors.
Yes, that's the point. I should clarify that the only reason
I had to put tar on a diet is that a week or so ago, I installed
On 09/12/2010 04:18 PM, Paul Eggert wrote:
While coding up recent changes to GNU tar, I discovered a
POSIX-emulation problem in gnulib's implementation of fdopendir.
I had written code like this:
DIR *dp = fdopendir (fd);
int fd1 = openat (fd, "subdir", O_RDONLY);
This works wi
Paul Eggert wrote:
> On 09/12/2010 10:25 PM, Jim Meyering wrote:
...
>> The POSIX wording allowing dirfd to fail on a valid stream is far older
>> than the *at functions, for which dirfd can now be essential. Given this
>> relatively new constraint, the odds of any new, useful system providing
>>
Bruno Haible wrote:
>> ... as part of my campaign to put GNU tar on a file descriptor diet ...
>
> Can you please say a few words about what it means, and what is the
> motivation?
>
> File descriptors are a central concept in POSIX. Is something wrong with it?
>
> To which class of programs does
Hi Paul,
> ... as part of my campaign to put GNU tar on a file descriptor diet ...
Can you please say a few words about what it means, and what is the motivation?
File descriptors are a central concept in POSIX. Is something wrong with it?
To which class of programs does this diet apply? To all
Hi Paul,
> Can dirfd really return -1 on real platforms, when its argument is a valid
> open directory stream? POSIX allows that behavior, but I don't know
> of any implementations that do it.
Nothing of this sort is known for Unix platforms, but
gnulib/doc/posix-functions/dirfd.texi mentions th
Paul Eggert wrote:
> I hope you don't mind a bit more code inspection of fts.c by someone
> who doesn't fully grok the code yet.
>
> I see that openat for directories is used in two places. One place
> uses O_NOFOLLOW if FTS_PHYSICAL is set; the other always follows
> symlinks. Is that intended?
I hope you don't mind a bit more code inspection of fts.c by someone
who doesn't fully grok the code yet.
I see that openat for directories is used in two places. One place
uses O_NOFOLLOW if FTS_PHYSICAL is set; the other always follows
symlinks. Is that intended? That is, wouldn't something l
22 matches
Mail list logo
