Are there any tools that can find potential errors in C source code? [closed]
For example, I have some code like this:
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
char *func(char *p) {
p = malloc(32);
memcpy(p, "hello", 6);
return p;
}
int main() {
char *s = NULL;
char *s2 = NULL;
s2 = func(s);
printf("%sn", s2);
free(s2);
return 1;
}
The code will work, but has a potential error that s
will not point to *p
(Suppose the programmer's intention is to allocate memory to s,). One can quickly find the error because it is very simple. But in a large project with many many codes, sometimes it is very hard to find an error like this. gcc -Wall -Wextra
does not give warnings.
Are there any tools that can find out this kind of error?
c gcc gcc-warning
closed as off-topic by Weather Vane, EvilTeach, John3136, RobC, gnat Nov 21 '18 at 9:23
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Weather Vane, EvilTeach, John3136, RobC, gnat
If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 2 more comments
For example, I have some code like this:
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
char *func(char *p) {
p = malloc(32);
memcpy(p, "hello", 6);
return p;
}
int main() {
char *s = NULL;
char *s2 = NULL;
s2 = func(s);
printf("%sn", s2);
free(s2);
return 1;
}
The code will work, but has a potential error that s
will not point to *p
(Suppose the programmer's intention is to allocate memory to s,). One can quickly find the error because it is very simple. But in a large project with many many codes, sometimes it is very hard to find an error like this. gcc -Wall -Wextra
does not give warnings.
Are there any tools that can find out this kind of error?
c gcc gcc-warning
closed as off-topic by Weather Vane, EvilTeach, John3136, RobC, gnat Nov 21 '18 at 9:23
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Weather Vane, EvilTeach, John3136, RobC, gnat
If this question can be reworded to fit the rules in the help center, please edit the question.
Valgrind, GDB, etc
– stackptr
Nov 21 '18 at 1:14
1
s
is not used at all after callingfunc
, so this is a weird example
– paddy
Nov 21 '18 at 1:23
2
It is not a "potential error thats
will not point to*p
". It is clear thats
is alwaysNULL
.
– Weather Vane
Nov 21 '18 at 1:25
@WeatherVane I think OP realizes this. It is an example of an "error" by not taking a pointer to pointer as an output parameter and having the function populate the pointer.
– TypeIA
Nov 21 '18 at 1:40
@TypeIA sinces
is never used, its role is unclear buts2
seems to be doing fine.
– Weather Vane
Nov 21 '18 at 1:43
|
show 2 more comments
For example, I have some code like this:
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
char *func(char *p) {
p = malloc(32);
memcpy(p, "hello", 6);
return p;
}
int main() {
char *s = NULL;
char *s2 = NULL;
s2 = func(s);
printf("%sn", s2);
free(s2);
return 1;
}
The code will work, but has a potential error that s
will not point to *p
(Suppose the programmer's intention is to allocate memory to s,). One can quickly find the error because it is very simple. But in a large project with many many codes, sometimes it is very hard to find an error like this. gcc -Wall -Wextra
does not give warnings.
Are there any tools that can find out this kind of error?
c gcc gcc-warning
For example, I have some code like this:
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
char *func(char *p) {
p = malloc(32);
memcpy(p, "hello", 6);
return p;
}
int main() {
char *s = NULL;
char *s2 = NULL;
s2 = func(s);
printf("%sn", s2);
free(s2);
return 1;
}
The code will work, but has a potential error that s
will not point to *p
(Suppose the programmer's intention is to allocate memory to s,). One can quickly find the error because it is very simple. But in a large project with many many codes, sometimes it is very hard to find an error like this. gcc -Wall -Wextra
does not give warnings.
Are there any tools that can find out this kind of error?
c gcc gcc-warning
c gcc gcc-warning
edited Nov 21 '18 at 1:33
gacopu
asked Nov 21 '18 at 1:06
gacopugacopu
1319
1319
closed as off-topic by Weather Vane, EvilTeach, John3136, RobC, gnat Nov 21 '18 at 9:23
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Weather Vane, EvilTeach, John3136, RobC, gnat
If this question can be reworded to fit the rules in the help center, please edit the question.
closed as off-topic by Weather Vane, EvilTeach, John3136, RobC, gnat Nov 21 '18 at 9:23
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Weather Vane, EvilTeach, John3136, RobC, gnat
If this question can be reworded to fit the rules in the help center, please edit the question.
Valgrind, GDB, etc
– stackptr
Nov 21 '18 at 1:14
1
s
is not used at all after callingfunc
, so this is a weird example
– paddy
Nov 21 '18 at 1:23
2
It is not a "potential error thats
will not point to*p
". It is clear thats
is alwaysNULL
.
– Weather Vane
Nov 21 '18 at 1:25
@WeatherVane I think OP realizes this. It is an example of an "error" by not taking a pointer to pointer as an output parameter and having the function populate the pointer.
– TypeIA
Nov 21 '18 at 1:40
@TypeIA sinces
is never used, its role is unclear buts2
seems to be doing fine.
– Weather Vane
Nov 21 '18 at 1:43
|
show 2 more comments
Valgrind, GDB, etc
– stackptr
Nov 21 '18 at 1:14
1
s
is not used at all after callingfunc
, so this is a weird example
– paddy
Nov 21 '18 at 1:23
2
It is not a "potential error thats
will not point to*p
". It is clear thats
is alwaysNULL
.
– Weather Vane
Nov 21 '18 at 1:25
@WeatherVane I think OP realizes this. It is an example of an "error" by not taking a pointer to pointer as an output parameter and having the function populate the pointer.
– TypeIA
Nov 21 '18 at 1:40
@TypeIA sinces
is never used, its role is unclear buts2
seems to be doing fine.
– Weather Vane
Nov 21 '18 at 1:43
Valgrind, GDB, etc
– stackptr
Nov 21 '18 at 1:14
Valgrind, GDB, etc
– stackptr
Nov 21 '18 at 1:14
1
1
s
is not used at all after calling func
, so this is a weird example– paddy
Nov 21 '18 at 1:23
s
is not used at all after calling func
, so this is a weird example– paddy
Nov 21 '18 at 1:23
2
2
It is not a "potential error that
s
will not point to *p
". It is clear that s
is always NULL
.– Weather Vane
Nov 21 '18 at 1:25
It is not a "potential error that
s
will not point to *p
". It is clear that s
is always NULL
.– Weather Vane
Nov 21 '18 at 1:25
@WeatherVane I think OP realizes this. It is an example of an "error" by not taking a pointer to pointer as an output parameter and having the function populate the pointer.
– TypeIA
Nov 21 '18 at 1:40
@WeatherVane I think OP realizes this. It is an example of an "error" by not taking a pointer to pointer as an output parameter and having the function populate the pointer.
– TypeIA
Nov 21 '18 at 1:40
@TypeIA since
s
is never used, its role is unclear but s2
seems to be doing fine.– Weather Vane
Nov 21 '18 at 1:43
@TypeIA since
s
is never used, its role is unclear but s2
seems to be doing fine.– Weather Vane
Nov 21 '18 at 1:43
|
show 2 more comments
1 Answer
1
active
oldest
votes
There is actually little wrong with that code other than abyssmal variable names :-)
A copy of s
is passed into the function as p
, you change p
then return it, finally assigning it to s2
. At no point is s
(or p
or s2
) used in a way that would cause undefined behaviour, unless the malloc
fails, which is something you should account for:
p = malloc(32);
if (p != NULL) memcpy(p, "hello", 6); // why not str[n]cpy ?
However, in terms of tools you can use to find problems, there are many. For example, linters, compilers with good diagnostic methods, memory trackers like valgrind
, and debuggers like gdb
.
By far the most important tool is the wetware inside that skull of yours, especially with your addition of:
Suppose the programmer's intention is to allocate memory to s.
I can think of no other tool that will catch the programmer's intention in that case. It's no different to figuring out the intent was to add two to a variable when the code states:
i++;
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is actually little wrong with that code other than abyssmal variable names :-)
A copy of s
is passed into the function as p
, you change p
then return it, finally assigning it to s2
. At no point is s
(or p
or s2
) used in a way that would cause undefined behaviour, unless the malloc
fails, which is something you should account for:
p = malloc(32);
if (p != NULL) memcpy(p, "hello", 6); // why not str[n]cpy ?
However, in terms of tools you can use to find problems, there are many. For example, linters, compilers with good diagnostic methods, memory trackers like valgrind
, and debuggers like gdb
.
By far the most important tool is the wetware inside that skull of yours, especially with your addition of:
Suppose the programmer's intention is to allocate memory to s.
I can think of no other tool that will catch the programmer's intention in that case. It's no different to figuring out the intent was to add two to a variable when the code states:
i++;
add a comment |
There is actually little wrong with that code other than abyssmal variable names :-)
A copy of s
is passed into the function as p
, you change p
then return it, finally assigning it to s2
. At no point is s
(or p
or s2
) used in a way that would cause undefined behaviour, unless the malloc
fails, which is something you should account for:
p = malloc(32);
if (p != NULL) memcpy(p, "hello", 6); // why not str[n]cpy ?
However, in terms of tools you can use to find problems, there are many. For example, linters, compilers with good diagnostic methods, memory trackers like valgrind
, and debuggers like gdb
.
By far the most important tool is the wetware inside that skull of yours, especially with your addition of:
Suppose the programmer's intention is to allocate memory to s.
I can think of no other tool that will catch the programmer's intention in that case. It's no different to figuring out the intent was to add two to a variable when the code states:
i++;
add a comment |
There is actually little wrong with that code other than abyssmal variable names :-)
A copy of s
is passed into the function as p
, you change p
then return it, finally assigning it to s2
. At no point is s
(or p
or s2
) used in a way that would cause undefined behaviour, unless the malloc
fails, which is something you should account for:
p = malloc(32);
if (p != NULL) memcpy(p, "hello", 6); // why not str[n]cpy ?
However, in terms of tools you can use to find problems, there are many. For example, linters, compilers with good diagnostic methods, memory trackers like valgrind
, and debuggers like gdb
.
By far the most important tool is the wetware inside that skull of yours, especially with your addition of:
Suppose the programmer's intention is to allocate memory to s.
I can think of no other tool that will catch the programmer's intention in that case. It's no different to figuring out the intent was to add two to a variable when the code states:
i++;
There is actually little wrong with that code other than abyssmal variable names :-)
A copy of s
is passed into the function as p
, you change p
then return it, finally assigning it to s2
. At no point is s
(or p
or s2
) used in a way that would cause undefined behaviour, unless the malloc
fails, which is something you should account for:
p = malloc(32);
if (p != NULL) memcpy(p, "hello", 6); // why not str[n]cpy ?
However, in terms of tools you can use to find problems, there are many. For example, linters, compilers with good diagnostic methods, memory trackers like valgrind
, and debuggers like gdb
.
By far the most important tool is the wetware inside that skull of yours, especially with your addition of:
Suppose the programmer's intention is to allocate memory to s.
I can think of no other tool that will catch the programmer's intention in that case. It's no different to figuring out the intent was to add two to a variable when the code states:
i++;
edited Nov 21 '18 at 1:37
answered Nov 21 '18 at 1:26
paxdiablopaxdiablo
631k16912431666
631k16912431666
add a comment |
add a comment |
Valgrind, GDB, etc
– stackptr
Nov 21 '18 at 1:14
1
s
is not used at all after callingfunc
, so this is a weird example– paddy
Nov 21 '18 at 1:23
2
It is not a "potential error that
s
will not point to*p
". It is clear thats
is alwaysNULL
.– Weather Vane
Nov 21 '18 at 1:25
@WeatherVane I think OP realizes this. It is an example of an "error" by not taking a pointer to pointer as an output parameter and having the function populate the pointer.
– TypeIA
Nov 21 '18 at 1:40
@TypeIA since
s
is never used, its role is unclear buts2
seems to be doing fine.– Weather Vane
Nov 21 '18 at 1:43