Are there any tools that can find potential errors in C source code? [closed]












-1















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?










share|improve this 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 calling func, 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 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











  • @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
















-1















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?










share|improve this 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 calling func, 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 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











  • @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














-1












-1








-1








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 calling func, 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 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











  • @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



















  • Valgrind, GDB, etc

    – stackptr
    Nov 21 '18 at 1:14






  • 1





    s is not used at all after calling func, 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 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











  • @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

















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












1 Answer
1






active

oldest

votes


















1














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++;





share|improve this answer
































    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    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++;





    share|improve this answer






























      1














      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++;





      share|improve this answer




























        1












        1








        1







        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++;





        share|improve this answer















        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++;






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 21 '18 at 1:37

























        answered Nov 21 '18 at 1:26









        paxdiablopaxdiablo

        631k16912431666




        631k16912431666















            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            Origin of the phrase “under your belt”?