On 2018-09-12 at 16:25, Shi Lei wrote: On 2018-09-12 at 15:21, Erik Skultety wrote: >On Tue, Sep 11, 2018 at 11:37:45PM +0800, Shi Lei wrote: >> On 2018-09-11 at 20:44, Erik Skultety wrote: >> >On Mon, Sep 10, 2018 at 11:47:53AM +0800, Shi Lei wrote: >> >> By making use of GNU C's cleanup attribute handled by the VIR_AUTOCLOSE macro, >> >> many of the VIR_FORCE_CLOSE calls can be dropped, which in turn leads to >> >> getting rid of many of our cleanup sections. >> >> >> >> Signed-off-by: Shi Lei <shi_lei@xxxxxxxxxxxxxx> >> >> --- >> >> static int >> >> @@ -909,9 +867,9 @@ char *virNetDevGetName(int ifindex) >> >> #if defined(SIOCGIFINDEX) && defined(HAVE_STRUCT_IFREQ) >> >> int virNetDevGetIndex(const char *ifname, int *ifindex) >> >> { >> >> - int ret = -1; >> >> struct ifreq ifreq; >> >> - int fd = socket(VIR_NETDEV_FAMILY, SOCK_DGRAM, 0); >> >> + VIR_AUTOCLOSE(fd); >> >> + socket(VIR_NETDEV_FAMILY, SOCK_DGRAM, 0); >> > >> >^this could not potentially work... >> > >> >Erik >> >> Sorry! I'm too careless. >> >> I think that a new syntax-check rule might make sense. >> This rule checks below: >> >> type foo(a0, a1 ...); >> >> [type] var = foo(a0, a1, ...); /* It's OK */ >> ignore_value(foo(a0, a1, ...)); /* It's OK */ >> >> foo(a0, a1, ...); /* Report this usage */ > >but this would go away with the syntax-check rule you proposed in you response >to the first patch? If not, then would you be more specific to help me >understand the problem more? > >Thanks, >Erik Sorry! I was muddle-headed last night. It is not the syntax-check rule in my response to the first patch. This is another rule and I wanted to introduce it to avoid some faults then. Today I find that it is not easy as I thought. Please ignore it ... :-) Shi Lei > >> >> And it takes effect before compilation and even it's in the inactive >> side of the #if-#else conditons. >> >> It would not check macros since their name are upper case and >> we don't care for the function as condition in if-else statement. >> >> How about it? >> And I can try it if it's a bit helpful ... >> >> Shi Lei >> >> >> >> -- >> libvir-list mailing list >> libvir-list@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list