[PATCH] daemon.c: mark a file-local symbol as static

[PATCH] daemon.c: mark a file-local symbol as static

[Ramsay Jones]

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

Hi Jeff,

If you need to re-roll your 'jk/tighten-alloc' branch, could you
please squash this into the relevant patch. (ie. "convert manual
allocations to argv_array").

Thanks!

ATB,
Ramsay Jones

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

diff --git a/daemon.c b/daemon.c
index 3f57adb..8d45c33 100644
--- a/daemon.c
+++ b/daemon.c
@@ -808,7 +808,7 @@ static void check_dead_children(void)
 			cradle = &blanket->next;
 }
 
-struct argv_array cld_argv = ARGV_ARRAY_INIT;
+static struct argv_array cld_argv = ARGV_ARRAY_INIT;
 static void handle(int incoming, struct sockaddr *addr, socklen_t addrlen)
 {
 	struct child_process cld = CHILD_PROCESS_INIT;
-- 
2.7.0

Re: [PATCH] daemon.c: mark a file-local symbol as static

[Jeff King]

On Sun, Feb 21, 2016 at 05:33:38PM +0000, Ramsay Jones wrote:

> If you need to re-roll your 'jk/tighten-alloc' branch, could you
> please squash this into the relevant patch. (ie. "convert manual
> allocations to argv_array").

Thanks, will do. You notice these with sparse, as I recall? I've meant
to look into running that myself, but it looks like we are not
warning-free with sparse currently. I see complaints like:

  connect.c:377:40: warning: incorrect type in argument 2 (invalid types)
  connect.c:377:40:    expected union __CONST_SOCKADDR_ARG [usertype] __addr
  connect.c:377:40:    got struct sockaddr *ai_addr

As far as I can tell, that's just noise. Do you have a ready-made recipe
for silencing it?

-Peff

Re: [PATCH] daemon.c: mark a file-local symbol as static

[Ramsay Jones]

On 21/02/16 23:25, Jeff King wrote:
> On Sun, Feb 21, 2016 at 05:33:38PM +0000, Ramsay Jones wrote:
> 
>> If you need to re-roll your 'jk/tighten-alloc' branch, could you
>> please squash this into the relevant patch. (ie. "convert manual
>> allocations to argv_array").
> 
> Thanks, will do. You notice these with sparse, as I recall? I've meant
> to look into running that myself, but it looks like we are not
> warning-free with sparse currently. I see complaints like:
> 
>   connect.c:377:40: warning: incorrect type in argument 2 (invalid types)
>   connect.c:377:40:    expected union __CONST_SOCKADDR_ARG [usertype] __addr
>   connect.c:377:40:    got struct sockaddr *ai_addr
> 
> As far as I can tell, that's just noise. Do you have a ready-made recipe
> for silencing it?

Ah, I think you must be on a very old version of sparse.

I tend to run a (non-released, reasonably) up-to-date version built
directly from the sparse repo at:

    git://git.kernel.org/pub/scm/devel/sparse/sparse.git

[You just prompted me to check, I'm running version v0.5.0-30-gca3309e
which is actually a little behind master, which is v0.5.0-44-g40791b9.
This is even further behind the maintainers master branch.]

On Linux, there is a single warning, which results from a hard-coded
value (max size of memcpy et. al., used for the kernel) which should
at least be settable from the command line (I have a patch somewhere
which I have not sent upstream).

On cygwin, currently, there are several other warnings, which can be
silenced by fixups to sparse (again I have some patches ...)

(Also, static-check.pl comes in handy for these types of 'problem'.)

HTH

ATB,
Ramsay Jones

Re: [PATCH] daemon.c: mark a file-local symbol as static

[Jeff King]

On Mon, Feb 22, 2016 at 12:33:23AM +0000, Ramsay Jones wrote:

> > Thanks, will do. You notice these with sparse, as I recall? I've meant
> > to look into running that myself, but it looks like we are not
> > warning-free with sparse currently. I see complaints like:
> > 
> >   connect.c:377:40: warning: incorrect type in argument 2 (invalid types)
> >   connect.c:377:40:    expected union __CONST_SOCKADDR_ARG [usertype] __addr
> >   connect.c:377:40:    got struct sockaddr *ai_addr
> > 
> > As far as I can tell, that's just noise. Do you have a ready-made recipe
> > for silencing it?
> 
> Ah, I think you must be on a very old version of sparse.

I have whatever comes with debian unstable. Looks like 0.5.0 from
November. So not _that_ old, but I can well believe it is missing tweaks
found at the tip of their development.

I guess I was wondering whether I should be adding "make sparse" to my
set of pre-submission checks. But I can't say I'm enthused about
manually keeping another tool up to date. :)

> On Linux, there is a single warning, which results from a hard-coded
> value (max size of memcpy et. al., used for the kernel) which should
> at least be settable from the command line (I have a patch somewhere
> which I have not sent upstream).

Yeah, I saw that one, for a large zeroing memset of a heap buffer. I
don't think it's _wrong_, though it would probably not hurt to use
xcalloc instead.

Thanks for the pointers.

-Peff

Re: [PATCH] daemon.c: mark a file-local symbol as static

[Ramsay Jones]

On 22/02/16 21:18, Jeff King wrote:
> On Mon, Feb 22, 2016 at 12:33:23AM +0000, Ramsay Jones wrote:
> 
>>> Thanks, will do. You notice these with sparse, as I recall? I've meant
>>> to look into running that myself, but it looks like we are not
>>> warning-free with sparse currently. I see complaints like:
>>>
>>>   connect.c:377:40: warning: incorrect type in argument 2 (invalid types)
>>>   connect.c:377:40:    expected union __CONST_SOCKADDR_ARG [usertype] __addr
>>>   connect.c:377:40:    got struct sockaddr *ai_addr
>>>
>>> As far as I can tell, that's just noise. Do you have a ready-made recipe
>>> for silencing it?
>>
>> Ah, I think you must be on a very old version of sparse.
> 
> I have whatever comes with debian unstable. Looks like 0.5.0 from
> November. So not _that_ old, but I can well believe it is missing tweaks
> found at the tip of their development.

Yes, but that version was released in Jan 2014!

> I guess I was wondering whether I should be adding "make sparse" to my
> set of pre-submission checks. But I can't say I'm enthused about
> manually keeping another tool up to date. :)

Hmm, probably not worth it - I sometimes wonder why I bother! :-D

ATB,
Ramsay Jones