On 2 February 2015 at 06:22, Ola Liljedahl <[email protected]> wrote:
> On 2 February 2015 at 12:18, Ola Liljedahl <[email protected]> > wrote: > > On 2 February 2015 at 12:05, Maxim Uvarov <[email protected]> > wrote: > >> On 01/29/2015 01:39 PM, Ola Liljedahl wrote: > >>> > >>> num_workers = odph_linux_cpumask_default(&cpumask, > num_workers); > >>> - odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr)); > >>> + size_t bufsz = sizeof(cpumaskstr); > >>> + (void)odp_cpumask_to_str(&cpumask, cpumaskstr, &bufsz); > >>> > >> > >> > >> why did add this (void)? > > Because odp_cpumask_to_str() has a return value that you normally > > should check. If I think the return value for some reason doesn't > > merit checking, then I cast the function call to "(void)". > > > > If you are closing a file/socket descriptor you have written to, you > > should check the return value from close() because writes may have > > been buffered and close may fail writing out your data.. But if the > > file descriptor was e.g. only used for reading, then you don't need to > > check the return value from close(). Ideally the compiler should warn > > if you are not checking the return value from close() and in the > > second case above, you would use "(void)close(fd);". > > > > I think the compiler can warn if return values are not used. Possibly > > this is controlled using some GCC attribute. > > http://stackoverflow.com/questions/2870529/g-how-to-get-warning-on-ignoring-function-return-value > > Something for ODP? > Looks reasonable - coverity is currently list two such cases, it is smart enough to work out that you "usually" check the return for a particular function rather than just warn every time CID 85004: Unchecked return value (CHECKED_RETURN)6. check_return: Calling _odp_packet_copy_to_packet without checking return value (as is done elsewhere 5 out of 6 times). 369 _odp_packet_copy_to_packet(params->pkt, 0, params-> out_pkt, 0, 370 odp_packet_len(params->pkt)); > > > BTW: This patch series is obsolete, I am currently rebasing it. > > > > > >> > >> Maxim. > >> > >> _______________________________________________ > >> lng-odp mailing list > >> [email protected] > >> http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
