<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>change log for rtems-testing (2010-08-09)</title>
</head>
<body text='#000000' bgcolor='#ffffff'>
<a name='cs1'></a>
<table border='0' cellspacing='0' cellpadding='5' width='100%' bgcolor='#eeeeee'>
<tr><td colspan='3' bgcolor='#dddddd'>
 <font color='#bb2222'><strong>joel</strong></font>
</td></tr>
<tr><td colspan='3' bgcolor='#dddddd'><pre>2010-08-09 Bharath Suri <bharath.s.jois@gmail.com>

        PR 1659/testing
        * Explanations.txt: Update.
</pre></td></tr>
<tr><td width='1%'><a href="http://www.rtems.com/cgi-bin/viewcvs.cgi//rtems-testing/rtems-coverage/ChangeLog.diff?r1=text&tr1=1.289&r2=text&tr2=1.290&diff_format=h">M</a></td><td width='1%'>1.290</td><td width='100%'>rtems-coverage/ChangeLog</td></tr>
<tr><td width='1%'><a href="http://www.rtems.com/cgi-bin/viewcvs.cgi//rtems-testing/rtems-coverage/Explanations.txt.diff?r1=text&tr1=1.69&r2=text&tr2=1.70&diff_format=h">M</a></td><td width='1%'>1.70</td><td width='100%'>rtems-coverage/Explanations.txt</td></tr>
</table>
<pre>
<font color='#006600'>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
</font><font color='#997700'>@@ -1,3 +1,8 @@
</font><font color='#000088'>+2010-08-09    Bharath Suri <bharath.s.jois@gmail.com>
+
+       PR 1659/testing
+       * Explanations.txt: Update.
+
</font> 2010-08-04        Joel Sherrill <joel.sherrill@oarcorp.com>
 
        * do_coverage: Add remove_unwanted_symbols.

<font color='#006600'>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
</font><font color='#997700'>@@ -1,31 +1,25 @@
</font> privateenv.c:43
<font color='#880000'>-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.
</font><font color='#000088'>+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
</font> +++
 
 imfs_fifo.c:61
<font color='#880000'>-Requires Discussion
</font><font color='#000088'>+Unreachable
</font> 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
<font color='#880000'>-Simple Test Case
-Appprently we never call this with ".." for the parent directory.
</font><font color='#000088'>+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 ".."
</font> +++
 
 imfs_fsunmount.c:86
<font color='#997700'>@@ -38,13 +32,6 @@
</font> I think he wrote this code and can probably identify the test case.
 +++
 
<font color='#880000'>-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.
-+++
-
</font> imfs_mount.c:44
 Unreachable?
 We need to ask Chris Johns about this. I believe this is a
<font color='#997700'>@@ -52,12 +39,7 @@
</font> call layer.  I analyzed the "file handlers" callbacks for
 guarantees on parameters.  This indicates the same analysis
 needs to happen for "file system handlers."
<font color='#880000'>-+++
-
-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.
</font><font color='#000088'>+Bharath: Yes, it is checked in mount.c
</font> +++
 
 imfs_debug.c:54
<font color='#997700'>@@ -70,13 +52,17 @@
</font> imfs_debug.c:88
 Simple Test Case
 We need to do an IMFS_dump on an IMFS filesystem which has a bad node type
<font color='#880000'>-in it.  This may require peeking behind the curtain and changing a value.
</font><font color='#000088'>+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.
</font> +++
 
 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.
<font color='#000088'>+Bharath: I am not sure how to have a node's parent == NULL.
</font> +++
 
 imfs_unlink.c:51
<font color='#997700'>@@ -97,35 +83,6 @@
</font> to discuss this to figure out which.
 +++<span style="background-color: #FF0000"> </span>
 
<font color='#880000'>-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<span style="background-color: #FF0000"> </span>
-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<span style="background-color: #FF0000"> </span>
-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.
-+++
-
</font> newlibc_exit.c:89
 Simple Test Case
 libc_wrapup() is never called when the system state is down.
<font color='#997700'>@@ -144,19 +101,6 @@
</font> from the buffer.  But I am not sure.
 +++
 
<font color='#880000'>-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
-+++
-
</font> getpwent.c:112
 Simple Test Case
 
<font color='#997700'>@@ -214,3 +158,35 @@
</font> Email Sebastian
 Sebastian needs to write a test case for this.
 +++
<font color='#000088'>+
+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.
++++
</font></pre>
<p> </p>

<p>--<br />
<small>Generated by <a href="http://www.codewiz.org/projects/index.html#loginfo">Deluxe Loginfo</a> 2.122 by Bernardo Innocenti <bernie@develer.com></small></p>
</body>
</html>