change log for rtems-testing (2010-08-09)
rtems-vc at rtems.org
rtems-vc at rtems.org
Mon Aug 9 14:10:05 UTC 2010
*joel*:
2010-08-09 Bharath Suri <bharath.s.jois at gmail.com>
PR 1659/testing
* Explanations.txt: Update.
M 1.290 rtems-coverage/ChangeLog
M 1.70 rtems-coverage/Explanations.txt
diff -u rtems-testing/rtems-coverage/ChangeLog:1.289 rtems-testing/rtems-coverage/ChangeLog:1.290
--- rtems-testing/rtems-coverage/ChangeLog:1.289 Wed Aug 4 08:35:20 2010
+++ rtems-testing/rtems-coverage/ChangeLog Mon Aug 9 08:20:28 2010
@@ -1,3 +1,8 @@
+2010-08-09 Bharath Suri <bharath.s.jois at gmail.com>
+
+ PR 1659/testing
+ * Explanations.txt: Update.
+
2010-08-04 Joel Sherrill <joel.sherrill at oarcorp.com>
* do_coverage: Add remove_unwanted_symbols.
diff -u rtems-testing/rtems-coverage/Explanations.txt:1.69 rtems-testing/rtems-coverage/Explanations.txt:1.70
--- rtems-testing/rtems-coverage/Explanations.txt:1.69 Mon Aug 2 11:28:03 2010
+++ rtems-testing/rtems-coverage/Explanations.txt Mon Aug 9 08:20:28 2010
@@ -1,31 +1,25 @@
privateenv.c:43
-Simple Test Case
-free_user_env is never called when (env == &rtems_global_user_env). It is
-possible that this path is impossible but that will require analysis of the
-callers. Since this is static, it is quite possible this is covered by
-the callers.
-+++
-
-imfs_chown.c:46
-Simple Test Case
-Not root and not owner. Please try to cover all branch paths.
-+++
-
-imfs_fchmod.c:42
-Simple Test Case
-Not root and not owner. Please try to cover all branch paths.
+Unreachable
+free_user_env is never called when (env == &rtems_global_user_env).
+This check is done by the caller (rtems_libio_share_private_env) in a different manner as below:
+"if (rtems_current_user_env->task_id==current_task_id) {"
+This makes sure that free_user_env is not called venv == &rtems_global_user_env
+++
imfs_fifo.c:61
-Requires Discussion
+Unreachable
This is an error return path which only returns an error when
pipe_release() returns an error but pipe_release() can't return
an error. Maybe pipe_release() should be changed to void.
+++
imfs_getchild.c:51
-Simple Test Case
-Appprently we never call this with ".." for the parent directory.
+Unreachable
+This code cannot be reached. The routine IMFS_find_match_in_dir is
+called only if the token type is IMFS_NAME. If ".." is present in the
+path, the token type returned by IMFS_get_token would be
+IMFS_DIR_UP. With such a setup, IMFS_find_match_in_dir cannot be
+called with the name as ".."
+++
imfs_fsunmount.c:86
@@ -38,13 +32,6 @@
I think he wrote this code and can probably identify the test case.
+++
-imfs_initsupp.c:55
-Requires Discussion
-I think this is an error case that cannot be reached. The
-bytes_per_block is set by confdefs.h and there are error checks
-in that to prevent a bad value.
-+++
-
imfs_mount.c:44
Unreachable?
We need to ask Chris Johns about this. I believe this is a
@@ -52,12 +39,7 @@
call layer. I analyzed the "file handlers" callbacks for
guarantees on parameters. This indicates the same analysis
needs to happen for "file system handlers."
-+++
-
-imfs_debug.c:43
-Simple Test Case
-Need to do an IMFS_dump after loading a tarfile from memory.
-I think this is a simple addition to tar01.
+Bharath: Yes, it is checked in mount.c
+++
imfs_debug.c:54
@@ -70,13 +52,17 @@
imfs_debug.c:88
Simple Test Case
We need to do an IMFS_dump on an IMFS filesystem which has a bad node type
-in it. This may require peeking behind the curtain and changing a value.
+in it. This may require peeking behind the curtain and changing a
+value.
+Bharath: But usually, this code is unreachable since we cannot create
+a node which is not of type that is checked for.
+++
imfs_rename.c:40
Discuss
I think this is either a simple test or unreachable code. We need
to discuss this to figure out which.
+Bharath: I am not sure how to have a node's parent == NULL.
+++
imfs_unlink.c:51
@@ -97,35 +83,6 @@
to discuss this to figure out which.
+++
-dup2.c:51
-Simple Test Case
-This looks like we never get to the bottom to actually call fcntl()
-which I take to mean that we do not have a test for a working call
-to dup2().
-
-But we need to be careful because fcntl(F_DUPFD) which is called has
-slightly different semantics. I suspect that fcntl(F_DUPFD) is wrong.
-See fcntl.c:55 for more details.
-+++
-
-fcntl.c:55
-Discuss
-I question that this is correct. We are calling this from dup2()
-and the semantics are slightly different. fcntl is
-I suspect that by adding a shared routine and calling it from fcntl()
-and and dup2() we can fix this.
-+++
-
-fcntl.c:83
-Simple Test Case
-We need a test setting close on exec.
-+++
-
-fcntl.c:143
-Simple Test Case
-None of the file system specific handlers have ever returned an error here.
-+++
-
newlibc_exit.c:89
Simple Test Case
libc_wrapup() is never called when the system state is down.
@@ -144,19 +101,6 @@
from the buffer. But I am not sure.
+++
-getpwent.c:141
-Simple Test Case
-I think this is a matter of putting in a VERY large number in
-a numeric field. This is detecting overflow. I think a long
-string of 9's will do most of this.
-+++
-
-getpwent.c:142
-Simple Test Case
-
-See getpwent.c:141
-+++
-
getpwent.c:112
Simple Test Case
@@ -214,3 +158,35 @@
Email Sebastian
Sebastian needs to write a test case for this.
+++
+
+eval.c:95
+Discuss
+This, I feel is a valid test unless we have certain guidelines / tests
+to be done in the callers.
+Or we could have a new test that directly calls the
+rtems_filesystem_evaluate_path, if that is OK.
++++
+
+eval.c:98
+Discuss
+This, I feel is a valid test unless we have certain guidelines / tests
+to be done in the callers.
+Or we could have a new test that directly calls the
+rtems_filesystem_evaluate_path, if that is OK.
++++
+
+eval.c:40
+Discuss
+This, I feel is a valid test unless we have certain guidelines / tests
+to be done in the callers.
+Or we could have a new test that directly calls the
+rtems_filesystem_evaluate_relative_path, if that is OK.
++++
+
+eval.c:43
+Discuss
+This, I feel is a valid test unless we have certain guidelines / tests
+to be done in the callers.
+Or we could have a new test that directly calls the
+rtems_filesystem_evaluate_relative_path, if that is OK.
++++
--
Generated by Deluxe Loginfo [http://www.codewiz.org/projects/index.html#loginfo] 2.122 by Bernardo Innocenti <bernie at develer.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/vc/attachments/20100809/08fd80ac/attachment.html>
More information about the vc
mailing list