Fix issues found by static analysis.tizen_5.5.m2_releasesubmit/tizen_5.5_mobile_hotfix/20201026.185104submit/tizen_5.5/20191031.000004submit/tizen/20190926.122500accepted/tizen/unified/20190927.013321accepted/tizen/5.5/unified/mobile/hotfix/20201027.085839accepted/tizen/5.5/unified/20191031.021742tizen_5.5_mobile_hotfixaccepted/tizen_5.5_unified_mobile_hotfix

Change-Id: I4d1e87a5e3b8091f5503d105a41764358e5b6840
Signed-off-by: Michal Bloch <m.bloch@samsung.com>

3 files changed, 15 insertions, 14 deletions

diff --git a/src/logger/logger.c b/src/logger/logger.c
index 175c0997..19d2f2f6 100644
--- a/src/logger/logger.c
+++ b/src/logger/logger.c
@@ -1528,7 +1528,11 @@ static bool cond_service_reader(void *ptr, void *user_data)
 	 * logs to trigger the flush and so any FDs representing connections
 	 * to such buffer would leak until a log finally arrived (which could
 	 * be never). This is why waiting is also done on EPOLLHUP. */
-	modify_fd_entity(logger, &reader->fd_entity, (r == 0) ? EPOLLOUT : EPOLLHUP);
+	if (modify_fd_entity(logger, &reader->fd_entity, (r == 0) ? EPOLLOUT : EPOLLHUP) < 0) {
+		/* ignore, can't really happen and it's not
+		 * like we can do anything about it either */
+	}
+
 	return false;
 }
 
diff --git a/src/shared/ptrs_list.c b/src/shared/ptrs_list.c
index b734f6bb..f25c2fc2 100644
--- a/src/shared/ptrs_list.c
+++ b/src/shared/ptrs_list.c
@@ -153,6 +153,8 @@ list_head list_map(list_head head, void *user_data, map_cb map, apply_cb clear)
 		if (!new) {
 			if (clear)
 				list_clear_custom(&ret, user_data, clear);
+			else
+				list_clear(&ret);
 			return NULL;
 		}
 
@@ -160,6 +162,8 @@ list_head list_map(list_head head, void *user_data, map_cb map, apply_cb clear)
 			if (clear) {
 				clear(new, user_data);
 				list_clear_custom(&ret, user_data, clear);
+			} else {
+				list_clear(&ret);
 			}
 			return NULL;
 		}
diff --git a/src/shared/sort_vector.c b/src/shared/sort_vector.c
index 31d0a7a5..005d40f3 100644
--- a/src/shared/sort_vector.c
+++ b/src/shared/sort_vector.c
@@ -122,8 +122,6 @@ int sort_vector_push(struct sort_vector *logs, struct logger_entry *p, write_cal
 	assert(p);
 	assert(userdata);
 
-	int i;
-
 	if (sort_vector_full(logs)) {
 		if (logs->dump == DUMP_CONTINUOUS || logs->dump == DUMP_INFINITE) {
 			const int r = callback(sort_vector_back(logs), userdata);
@@ -174,8 +172,8 @@ int sort_vector_push(struct sort_vector *logs, struct logger_entry *p, write_cal
 	 * │2│3│6│7│9│
 	 * └─┴─┴─┴─┴─┘
 	 */
-	for (i = logs->end; i > logs->begin || (logs->end < logs->begin && i <= logs->end); --i) {
-		struct logger_entry *e = logs->data[(i ?: logs->size)-1];
+	int i;
+	for (i = logs->end; i > logs->begin || (logs->end < logs->begin && i <= logs->end); i = (i ?: logs->size) - 1) {
 		/* Note that in the case in which neither of p and e is earlier than the other, we pretend
 		 * e is earlier. This way, in the case of the invalid timestamps, we output the entries
 		 * in the order we receive them, because this best reflects the "true" order of those logs.
@@ -184,15 +182,10 @@ int sort_vector_push(struct sort_vector *logs, struct logger_entry *p, write_cal
 		 * always all of the entries we receive have the same timestamps. Also, in such cases
 		 * correct sorting is impossible anyway.
 		 */
-		if (log_entry_is_earlier(logs->sort_by, p, e)) {
-			logs->data[i] = e;
-		} else {
-			logs->data[i] = p;
-			logs->end = (logs->end + 1) % logs->size;
-			return 0;
-		}
-		if (!i)
-			i = logs->size;
+		struct logger_entry *const e = logs->data[(i ?: logs->size) - 1];
+		if (!log_entry_is_earlier(logs->sort_by, p, e))
+			break;
+		logs->data[i] = e;
 	}
 
 	logs->data[i] = p;