[LTP] [PATCH 1/4] syscalls/sync01: Remove it

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> 1) open(2) will return -1 if an error occur.
>      Is it necessary to check invalid return value(except -1) if an 
> error occur?

Well if there are values that are never supposed to be returned it makes
sense to catch these and return a TBROK or TFAIL.

If we are expecially testing a syscall() I would say that we should
check for all kinds of errors including the values that shall not be
returned e.g.:

	TEST(open(...));

	if (TST_RET == -1) {
		tst_ret(TFAIL | TTERRNO, "open() failed");
		return;
	}

	if (TST_RET < 0) {
		tst_ret(TFAIL | TTERRNO, "Invalid open() retval %ld", TST_RET);
		return;
	}

	...


If the syscall is part of the test preparation and there is no safe
macro I would say that it's enough to cover all invalid values in one
condition e.g.:

	fd = open(...);
	if (fd < 0)
		tst_brk(TBROK | TERRNO, "open() failed");


> 2) mmap(2) will return MAP_FAILED if an error occurs.
>      Is it necessary to check invalid value(except MAP_FAILED) if an 
> error occur?

Actually return value from mmap() is pointer, right? And the only value
that is not supposed to be returned is MAP_FAILED or do I miss
something?

> Martin's patches have added a check for invalid return value in many 
> safe macros but a lot of syscall tests(e.g. after doingTEST()) don't add 
> the check for now.
> I am not sure if we need to add the check for all syscall tests. :-)

I would say that at least for newly added test we should make sure that
there is no unexpected value returned.

> BTW: In my opinion, it is hardly to get invalid return value so the 
> check seems unnecessary and redundance.

Well it's not a common case but I've seen this to happen a few times,
once it was because a backported patch applied cleanly but the code was
incorrect and as a result syscall started to return really unexpected
values.

-- 
Cyril Hrubis
chrubis@suse.cz