On Tue, 09 Jun 2015 11:19:07 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> On 09/06/15 11:15, Carsten Haitzler wrote: > > On Tue, 09 Jun 2015 10:38:03 +0200 Stefan Schmidt <ste...@osg.samsung.com> > > said: > > > >> Hello. > >> > >> I just run through some of the coverity issues and spotted some where i > >> would the actual code author to have a look and either fix them or mark > >> as false positive. > >> > >> First of all the 4 issues with potential high impact: > >> > >> 1304728 Resource leak > >> <https://scan6.coverity.com:8443/docs/en/cov_checker_ref.html#static_checker_RESOURCE_LEAK> > >> in eo_lexer.c (q66) > >> 1297407 Resource leak > >> <https://scan6.coverity.com:8443/docs/en/cov_checker_ref.html#static_checker_RESOURCE_LEAK> > >> in eina_btlog.c (raster) > > > > if you know what the binary does/is for... this is zero impact :) > > > >> 1294210 Uninitialized scalar variable > >> <https://scan6.coverity.com:8443/docs/en/cov_checker_ref.html#static_checker_UNINIT> > >> in ector_software_rasterrizer.c (cedric) > >> 1267458 Read from pointer after free > >> <https://scan6.coverity.com:8443/docs/en/cov_checker_ref.html#static_checker_USE_AFTER_FREE> > >> in edje_pick.c (sachiel, maybe someone else if he is not around) > >> > >> And three more that jumped into my eye: > >> > >> 1304560 Bad bit shift operation > >> <https://scan6.coverity.com:8443/docs/en/cov_checker_ref.html#static_checker_BAD_SHIFT> > >> in evas_gl_core.c (Dongyeon Kim) > >> 1267475 Missing unlock > >> <https://scan6.coverity.com:8443/docs/en/cov_checker_ref.html#static_checker_LOCK> > >> in eina_thread_queue.c (raster) > > > > and i think coverity is wrong here. it THINKS sem_wait() is a lock... it's > > not. > > The link you pasted explicitly says that this call can block (lock). it can block.. but its not a lock requiring a matching unlokc in the fuciont like it thinks (like a mutex). sem_wait ..l waits until someone ELSe unlocks it. that is the whole POINT of a semaphore. > sem_wait() decrements (locks) the semaphore pointed to by sem. If the > semaphore's value is greater than zero, then the decrement proceeds, and > the function returns, immediately. If the semaphore currently has the > value zero, then the call blocks until either it becomes possible to > perform the decrement (i.e., the semaphore value rises above zero), or a > signal handler interrupts the call. and that is the whole POINT of a semaphore. it's something like a message queue just counting NUMBER of messages put into the box vs number taken out. so someone posts, somewhere else something waits. if there are no more things in the box, the wait .. waits, until someone does put something into the box... i can only conclude that coverity doesn't grok usage of semaphores. it thinks they are like mutexes. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
