Jim Meyering [EMAIL PROTECTED] wrote:
I propose to remove tests like this:
* lib/save-cwd.c (free_cwd): Remove now-useless if-before-free.
diff --git a/lib/save-cwd.c b/lib/save-cwd.c
index 7618f09..e158e8b 100644
--- a/lib/save-cwd.c
+++ b/lib/save-cwd.c
@@ -97,6 +97,5 @@ free_cwd
Eric Blake wrote:
As of git 1.5.4,
you can do 'git pull --rebase', to rebase all your local changes on the
current
branch on top of whatever upstream changes were made in the meantime
...
Oops - this put the upstream ChangeLog entries at the top of the file, in
front
of my entries
Jim Meyering wrote:
$ mkid ./build-aux/useless-if-before-free -l $(lid -knone free)|tr '\0'
'\n'
lib/csharpcomp.c
lib/fchdir.c
lib/free.c
lib/fstrcmp.c
lib/gc-gnulib.c
lib/getaddrinfo.c
lib/gl_carray_list.c
lib/localcharset.c
lib/lock.c
lib/printf-parse.c
lib/putenv.c
Bruno Haible [EMAIL PROTECTED] wrote:
While it is true that
if (p != NULL)
free (p);
is equivalent to
free (p);
the latter takes more instructions if there is a significant probability
that p is NULL. 2 instruction in the caller compared to a call instruction
and 6
Jim Meyering wrote:
I agree those should go, along with all of the others in tests/*.c.
I agree about the tests. Tests can afford small slowdowns.
I'd like to avoid spending time looking for ways to micro-optimize.
How about if I remove them all, and then restore-with-justification
the ones
Hello Bruno,
the commit below removed some 14000 lines from the ChangeLog file.
I hope that wasn't the reason for the speedup, ;-)
but please check whether a bug in git-merge-changelog was
responsible for this.
Cheers,
Ralf
commit 65bd10479d4cb86bab4aea1424c094f8f585000c
Author: Bruno Haible
Hello Ralf,
the commit below removed some 14000 lines from the ChangeLog file.
Already restored a few hours ago. But thanks for noticing it.
I hope that wasn't the reason for the speedup, ;-)
Hehe ;-) No, I was working on copies that were not truncated.
but please check whether a bug in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to John E. Malmberg on 2/18/2008 8:46 PM:
| I have run into a problem: GNU TAR now requires that the open() call
| support O_DIRECTORY.
Tar is using O_DIRECTORY to close a security hole, and not to directly
read the directory contents.
Hello,
I am trying to get gnu tar to build on VMS.
I have run into a problem: GNU TAR now requires that the open() call
support O_DIRECTORY.
On the VMS platform, this support is not available. Using open() on a
directory will always fail. Only opendir() can be used, and readdir()
must be
