On Tue, Dec 16, 2014 at 12:25:22PM +0000, Ola Liljedahl wrote: > On 16 December 2014 at 12:36, Stuart Haslam <[email protected]> wrote: > > On Tue, Dec 16, 2014 at 10:52:02AM +0000, Ola Liljedahl wrote: > >> On 16 December 2014 at 10:50, Stuart Haslam <[email protected]> wrote: > >> > On Mon, Dec 15, 2014 at 08:15:03PM +0000, Mike Holmes wrote: > >> >> Logic error Assigned value is garbage or undefined odp_linux.c > >> >> 185 8 View > >> >> Report<http://docs.opendataplane.org/clang-scan/report-1a7998.html#EndPath> > >> > > >> > This is a false positive, status is initialised in wait(). I guess > >> > clang-check could be made happy by explicitly initialising it, but > >> > it's not needed and would probably cause some other tool to complain, > >> > so I'd just ignore it. > >> Would it help if variables were declared as close to their usage as > >> possible instead of being declared on the outermost function level? > > > > I doubt it would help here as I assume clang-check just doesn't know > > that wait() updates status. > How can it not know or assume? wait() takes a pointer to an int (and > not a pointer to a const int), the prototype should be available to > clang-check. If the checker did not assume that a variable passed by > reference (non-const pointer) to a function was going to be written by > that function, then we ought to get a lot of false positives. Is there > something specific about this warning? >
Perhaps wait() is a bit special, the prototype is actually; __pid_t wait (__WAIT_STATUS __stat_loc); Because if you have __USE_BSD defined the status type is a "funky union", in our case it's a simple int * but maybe something in wait.h confuses clang-check. Anyhow there's an open bug for the same; http://llvm.org/bugs/show_bug.cgi?id=19493 > > > >> int i; > >> for (i = 0; i < num; i++) { > >> int j; > >> int status; > >> pid_t pid = wait(&status); > >> > >> etc. > > > > .. though I agree that's an improvement. > > > >> > >> This function returns -1 for some error cases. Are those error cases > >> expected to occur in normal successful execution? I don't think so. > >> Better to call ODP_ABORT() and not return. > >> > > > > I agree. The thread and process helpers are pretty inconsistent at the > > minute, odph_linux_pthread_create() aborts on failure (although it > > doesn't have much error checking) whereas odph_linux_process_fork_n() > > returns -1. > And what is the caller of odph_linux_process_fork_n() supposed to do? > Does it even check the return value? > The only user is odp_example and that exits on fork failures and ignores wait failures. -- Stuart. _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
