daemon.c: mark a file-local symbol as static
PATCH 1/1 daemon.c: mark a file-local symbol as static
---
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(-)
daemon.c +1 -1
@@ -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 ;
Signature · 1 line
2.7.0
Quoted 3 lines · Ramsay Jones
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
Quoted 10 lines · Jeff King
Quoted 3 lines · Ramsay Jones
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:
Quoted 6 lines
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_addrAs 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
Quoted 4 lines · Ramsay Jones
Quoted 4 lines
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:
Quoted 8 lines
Quoted 6 lines
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_addrAs 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. :)
Quoted 4 lines
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
Quoted 10 lines · Jeff King
Quoted 8 lines · Ramsay Jones
Quoted 8 lines
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
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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!
Quoted 3 lines
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