* Question about unpack-trees.c and tree_entry_list
@ 2007-07-22 16:17 David Kastrup
2007-07-24 21:54 ` [PATCH] cleanup unpack-trees.c: shrink struct tree_entry_list René Scharfe
0 siblings, 1 reply; 2+ messages in thread
From: David Kastrup @ 2007-07-22 16:17 UTC (permalink / raw)
To: git
The definition of tree_entry_list ist the following
struct tree_entry_list {
struct tree_entry_list *next;
unsigned directory : 1;
unsigned executable : 1;
unsigned symlink : 1;
unsigned int mode;
const char *name;
const unsigned char *sha1;
};
but it appears to me that the only of the bit fields that is used at
all is "directory" : all other uses revert to "mode" which directory
presumably could do as well.
Is there something I am overlooking?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH] cleanup unpack-trees.c: shrink struct tree_entry_list
2007-07-22 16:17 Question about unpack-trees.c and tree_entry_list David Kastrup
@ 2007-07-24 21:54 ` René Scharfe
0 siblings, 0 replies; 2+ messages in thread
From: René Scharfe @ 2007-07-24 21:54 UTC (permalink / raw)
To: David Kastrup, Junio C Hamano; +Cc: git, Johannes Schindelin
David Kastrup schrieb:
> The definition of tree_entry_list ist the following
>
> struct tree_entry_list {
> struct tree_entry_list *next;
> unsigned directory : 1;
> unsigned executable : 1;
> unsigned symlink : 1;
> unsigned int mode;
> const char *name;
> const unsigned char *sha1;
> };
>
> but it appears to me that the only of the bit fields that is used at
> all is "directory" : all other uses revert to "mode" which directory
> presumably could do as well.
>
> Is there something I am overlooking?
A C compiler can give the definite answer: no.
--- 8< ---
Remove the two write-only fields executable and symlink from struct
tree_entry_list. Also replace usage of the field directory with
S_ISDIR checks on the mode field, and then remove this now obsolete
field, too. Noticed by David Kastrup.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
This patch slightly reduces RAM usage, but it also shrinks the code
without reducing functionality or readability, which is more
interesting.
unpack-trees.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 7cc029e..3b32718 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -11,9 +11,6 @@
struct tree_entry_list {
struct tree_entry_list *next;
- unsigned directory : 1;
- unsigned executable : 1;
- unsigned symlink : 1;
unsigned int mode;
const char *name;
const unsigned char *sha1;
@@ -38,9 +35,6 @@ static struct tree_entry_list *create_tree_entry_list(struct tree *tree)
entry->name = one.path;
entry->sha1 = one.sha1;
entry->mode = one.mode;
- entry->directory = S_ISDIR(one.mode) != 0;
- entry->executable = (one.mode & S_IXUSR) != 0;
- entry->symlink = S_ISLNK(one.mode) != 0;
entry->next = NULL;
*list_p = entry;
@@ -141,9 +135,9 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
#endif
if (!first || entcmp(first, firstdir,
posns[i]->name,
- posns[i]->directory) > 0) {
+ S_ISDIR(posns[i]->mode)) > 0) {
first = posns[i]->name;
- firstdir = posns[i]->directory;
+ firstdir = S_ISDIR(posns[i]->mode);
}
}
/* No name means we're done */
@@ -177,7 +171,7 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
continue;
}
- if (posns[i]->directory) {
+ if (S_ISDIR(posns[i]->mode)) {
struct tree *tree = lookup_tree(posns[i]->sha1);
any_dirs = 1;
parse_tree(tree);
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-07-24 21:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-22 16:17 Question about unpack-trees.c and tree_entry_list David Kastrup
2007-07-24 21:54 ` [PATCH] cleanup unpack-trees.c: shrink struct tree_entry_list René Scharfe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).