summaryrefslogtreecommitdiff
path: root/rtems-coverage/Explanations.txt
blob: 0d891dd04051c0b8f3a99709c2621f430529ea75 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
privateenv.c:43
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
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
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
Ask Chris Johns
I think he wrote this code and can probably identify the test case.
+++

imfs_fsunmount.c:93
Ask Chris Johns
I think he wrote this code and can probably identify the test case.
+++

imfs_mount.c:44
Unreachable?
We need to ask Chris Johns about this. I believe this is a
case where the error checking has been done by the system 
call layer.  I analyzed the "file handlers" callbacks for
guarantees on parameters.  This indicates the same analysis
needs to happen for "file system handlers."
Bharath: Yes, it is checked in mount.c
+++

imfs_debug.c:54
Simple Test Case
Need to do an IMFS_dump on an IMFS filesystem which has a very large
file in it.  I think this is a simple addition to one of the existing
IMFS tests which creates a large file.
+++

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.
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
Discuss
I think this is either a simple test or unreachable code.  We need
to discuss this to figure out which.
+++

imfs_unmount.c:45
Discuss
I think this is either a simple test or unreachable code.  We need
to discuss this to figure out which.
+++

imfs_unmount.c:52
Discuss
I think this is either a simple test or unreachable code.  We need
to discuss this to figure out which.
+++ 

newlibc_exit.c:89
Simple Test Case
libc_wrapup() is never called when the system state is down.
+++

readv.c:106
Simple Test Case
The count needs to be -1 in one of the requests.  Also add a test for
0 value at the same time since it appears that is a missing branch
condition.
+++

getpwent.c:127
Discuss
I think this is detecting whether or not the read can be fulfilled
from the buffer.  But I am not sure.
+++

getpwent.c:112
Simple Test Case

This is actually the error case at line 103 (*nleft < 2).  I think this
will be hit by having a password entry which does not have enough
characters left in the user's return buffer while something is
being copied into it.
+++

writev.c:104
Simple Test Case
This is a case of needing 0 values in the write iov entries.
+++

writev.c:113
Simple Test Case
This is a case of needing negative values in the write iov entries.
+++

vprintk.c:125
Simple Test Case
0x6f is a 'o'.  It looks like we do not have a printk test which uses %o.
+++

imfs_load_tar.c:112
Simple Test Case
Need to make sure one of the tar tests is configured with the IMFS
and the other is configured with fifoIMFS.
+++

imfs_load_tar.c:151
Simple Test Case
We apparently only have a relative symbolic link.  We need to include
one which has an absolute path. This will be a broken symlink on the
host but resolve fine on the target.
+++

imfs_load_tar.c:169
Medium Test Case
The eval for make must fail.  We will have to ask Jennifer how to
make this call fail.
+++

rtems_mkdir.c:102
Email Sebastian
Sebastian needs to write a test case for this.
+++

rtems_mkdir.c:110
Email Sebastian
Sebastian needs to write a test case for this.
+++

rtems_mkdir.c:124
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.
+++