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
sis 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 thatswill not point to*p". It is clear thatsis 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 sincesis never used, its role is unclear buts2seems 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
sis 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 thatswill not point to*p". It is clear thatsis 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 sincesis never used, its role is unclear buts2seems 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
sis 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 thatswill not point to*p". It is clear thatsis 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 sincesis never used, its role is unclear buts2seems 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
sis 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
swill not point to*p". It is clear thatsis 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
sis never used, its role is unclear buts2seems to be doing fine.– Weather Vane
Nov 21 '18 at 1:43