[PATCH] attr: mark a file-local symbol as static

[PATCH] attr: mark a file-local symbol as static

[Ramsay Jones]

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---

Hi Stefan,

If you need to re-roll your 'sb/attr' branch, could you please
squash this into the relevant patch.

Alternatively, since there is only a single call site for git_attr()
(on line #1005), you could perhaps remove git_attr() and inline that
call. (However, that does make that line exceed 80 columns).

Thanks!

ATB,
Ramsay Jones

 attr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/attr.c b/attr.c
index 667ba85..84c4b08 100644
--- a/attr.c
+++ b/attr.c
@@ -169,7 +169,7 @@ static struct git_attr *git_attr_internal(const char *name, int len)
 	return a;
 }
 
-struct git_attr *git_attr(const char *name)
+static struct git_attr *git_attr(const char *name)
 {
 	return git_attr_internal(name, strlen(name));
 }
-- 
2.10.0

Re: [PATCH] attr: mark a file-local symbol as static

[Stefan Beller]

On Sun, Nov 13, 2016 at 8:42 AM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> ---
>
> Hi Stefan,
>
> If you need to re-roll your 'sb/attr' branch, could you please
> squash this into the relevant patch.

will do. I have it applied locally

>
> Alternatively, since there is only a single call site for git_attr()
> (on line #1005), you could perhaps remove git_attr() and inline that
> call. (However, that does make that line exceed 80 columns).

I'll look into that.

Thanks,
Stefan

>
> Thanks!
>
> ATB,
> Ramsay Jones
>
>  attr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/attr.c b/attr.c
> index 667ba85..84c4b08 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -169,7 +169,7 @@ static struct git_attr *git_attr_internal(const char *name, int len)
>         return a;
>  }
>
> -struct git_attr *git_attr(const char *name)
> +static struct git_attr *git_attr(const char *name)
>  {
>         return git_attr_internal(name, strlen(name));
>  }
> --
> 2.10.0

[PATCH] attr: mark a file-local symbol as static

[Ramsay Jones]

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---

Hi Brandon,

If you need to re-roll your 'bw/attr' branch, could you please
squash this into the relevant patch (commit 8908457159,
"attr: use hashmap for attribute dictionary", 12-01-2017).

Also, I note that, although they are declared as part of the
public attr api, attr_check_clear() and attr_check_reset() are
also not called outside of attr.c. Are these functions part of
the public api?

Also, a minor point, but attr_check_reset() is called (line 1050)
before it's definition (line 1114). This is not a problem, given
the declaration in attr.h, but I prefer definitions to come before
use, where possible.

Thanks!

ATB,
Ramsay Jones


 attr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/attr.c b/attr.c
index f5cc68b67..e68c4688f 100644
--- a/attr.c
+++ b/attr.c
@@ -83,7 +83,7 @@ static int attr_hash_entry_cmp(const struct attr_hash_entry *a,
 }
 
 /* Initialize an 'attr_hashmap' object */
-void attr_hashmap_init(struct attr_hashmap *map)
+static void attr_hashmap_init(struct attr_hashmap *map)
 {
 	hashmap_init(&map->map, (hashmap_cmp_fn) attr_hash_entry_cmp, 0);
 }
-- 
2.11.0

Re: [PATCH] attr: mark a file-local symbol as static

[Brandon Williams]

On 01/18, Ramsay Jones wrote:
> 
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> ---
> 
> Hi Brandon,
> 
> If you need to re-roll your 'bw/attr' branch, could you please
> squash this into the relevant patch (commit 8908457159,
> "attr: use hashmap for attribute dictionary", 12-01-2017).
> 
> Also, I note that, although they are declared as part of the
> public attr api, attr_check_clear() and attr_check_reset() are
> also not called outside of attr.c. Are these functions part of
> the public api?
> 
> Also, a minor point, but attr_check_reset() is called (line 1050)
> before it's definition (line 1114). This is not a problem, given
> the declaration in attr.h, but I prefer definitions to come before
> use, where possible.
> 
> Thanks!
> 
> ATB,
> Ramsay Jones

Yes of course, I believe Stefan also pointed that out earlier today so I
have it fixed locally.

For attr_check_clear() and attr_check_reset() the intent is that they
are the accepted way to either clear or reset the attr_check structure.
Currently most users of the attribute system don't have a need to clear
or reset the structure but there could be future callers who need that
functionality.  If you feel like they shouldn't be part of the api right
now then I'm open to changing that for this series.

Thanks!

-- 
Brandon Williams

Re: [PATCH] attr: mark a file-local symbol as static

[Ramsay Jones]

On 18/01/17 23:05, Brandon Williams wrote:
> On 01/18, Ramsay Jones wrote:
>>
>> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
>> ---
>>
>> Hi Brandon,
>>
>> If you need to re-roll your 'bw/attr' branch, could you please
>> squash this into the relevant patch (commit 8908457159,
>> "attr: use hashmap for attribute dictionary", 12-01-2017).
>>
>> Also, I note that, although they are declared as part of the
>> public attr api, attr_check_clear() and attr_check_reset() are
>> also not called outside of attr.c. Are these functions part of
>> the public api?
>>
>> Also, a minor point, but attr_check_reset() is called (line 1050)
>> before it's definition (line 1114). This is not a problem, given
>> the declaration in attr.h, but I prefer definitions to come before
>> use, where possible.
>>
>> Thanks!
>>
>> ATB,
>> Ramsay Jones
> 
> Yes of course, I believe Stefan also pointed that out earlier today so I
> have it fixed locally.

Yep, I noticed Stefan's email just a few minutes after I hit
send! ;-)

> For attr_check_clear() and attr_check_reset() the intent is that they
> are the accepted way to either clear or reset the attr_check structure.
> Currently most users of the attribute system don't have a need to clear
> or reset the structure but there could be future callers who need that
> functionality.  If you feel like they shouldn't be part of the api right
> now then I'm open to changing that for this series.

No, I just wanted to check that they were intended to be part of
the public api and that you anticipate additional callers in the
future.

[I would still prefer definitions before use, but many people would
not agree with me, so ...]

ATB,
Ramsay Jones