0

We had a long debat and still no answer to this question related to the leaks in C programming, Here is a small example : 

    #include <stdlib.h>
    #include <string.h>
    #include <stdio.h>

    int main(int argc, char **argv)
    {
        char *s;

        if (s = (char *)malloc(7 + 1) == NULL)
           exit(1);
        s = strcpy(s, "bonjour");
        printf("%s\n", s);
        if (argc == 2)
           exit(1);
        else if (argc == 3)
           printf("I didn't free and exit normaly");
        else
           free(s);
        return (0);
     }

Here if we do a simple

gcc leaks.c -o leaks

./leaks will free and programme exit normaly

./leaks exit will exit without free

./leaks "nornamly" "exit wihtout free" will normaly exit but without free

which one of those three programme is the worst and the best. Well obviously the first is the best. but what about the two other ?

Do we really need to free as the programme exit just after and memory will be getting back by the OS ?

Thanks you everyone for this big question.

Damien Christophe
  • 115
  • 1
  • 1
  • 10
  • 1
    If you intend for your program to be long running, this is a bad habit to get into. – StoryTeller - Unslander Monica Mar 12 '18 at 13:20
  • 1
    Freeing memory not freed by the program is *a feature of the OS*. And more importantly, *not every OS does provide this feature*. Classic AmigaOS didn't, for example. If your program does not release all resources it allocated, your program is **faulty**, even if the OS covers your back. – DevSolar Mar 12 '18 at 13:21
  • Note that, while I closed this question as a duplicate, I consider the top answers to the linked question to be not explicit enough in pointing out that *not freeing resources before you exit is a programming error*. You should not rely on the OS to cover for your sins. – DevSolar Mar 12 '18 at 13:24
  • FWIW, AmigaOS didn't provide this feature because early Amiga's *did not have an MMU* and could not provide memory isolation of different processes. As they couldn't do it anyway, inter-process communication was implemented as simply passing a pointer to a message's memory around. This in turn meant that, at the end of a program's run time, the OS did not really "know" who "owned" a given piece of memory anyhow. So the OS basically said, clean up yourself please. Memory not `free()`d before exit was simply lost to the system. I would expect some embedded systems to be likely limited. – DevSolar Mar 12 '18 at 13:39
  • @DevSolar The reason those answers are "not explicit enough" for you is that this mantra of "thou shalt always free" is just an opinion; it is not an absolute fact. There are just about as many arguments in favor of the countervailing opinion, namely "let the OS free it for you". In particular, if doggedly trying to free everything makes your program buggy or slow, or if the effort takes away from the time you could spend adding necessary features or fixing user-impacting bugs, yer prolly doin it rong. – Steve Summit Mar 12 '18 at 13:59
  • See also [this other question](https://stackoverflow.com/questions/36584062/) and its answers. – Steve Summit Mar 12 '18 at 14:00
  • @DevSolar 'not freeing resources before you exit is a programming error' - sorry, but no, it is not. – Martin James Mar 12 '18 at 14:10
  • @DevSolar 'You should not rely on the OS to cover' - which has had more testing and validation - your OS or your own attempts at freeing memory? – Martin James Mar 12 '18 at 14:13
  • @MartinJames: And how do you know that the code you are writing will *always* and *only* run on an OS that *does* provide resource reclaiming? – DevSolar Mar 12 '18 at 14:15
  • Of course, if your process continually allocates and more and more memory during the run without limit, or loses track of memory it has allocated, (ie leaks), it's obviously a serious bug and must be fixed. – Martin James Mar 12 '18 at 14:16
  • @DevSolar are thare any OS in use today that do not manage process memory in a secure manner? Sure, little taskers on embedded do not, but developers on such systems temd to be highly skilled and know very well where and where not to allocate/free memory. Most such systems onl run one process anyway, and its thread/s never terminate. – Martin James Mar 12 '18 at 14:23
  • @MartinJames: A resource leak is a programming error, period. Whether or not the environment allows you to "get away with it" is orthogonal to that. – DevSolar Mar 12 '18 at 14:25
  • @DevSolar Most programming projects have a pretty good idea which platform (or which sorts of platforms) they're targeting. And most code that's written for high-level platforms (with a "real" OS, and an MMU, and all that) is not suitable for embedded work, for all sorts of reasons. Don't get me wrong, though -- "always free" is a fine mantra for lots of code -- just not for *all* code. It is not universal advice. – Steve Summit Mar 12 '18 at 14:30
  • @SteveSummit unfortunately, this 'you must explicitly free everything' matra is handed out by profs/TA's who have never actually had to face a real shutown of a non-trivial process and the nightmarish problems that can ensue by enforcing such rules. Just one is that, unlike the OS, user code cannot guarantee to be able to shut down all threads in a process before deallocating memory that those threads might be using. Applying the mantra then means that some processes cannot be shut down at all:( – Martin James Mar 12 '18 at 14:39
  • Just the terminology seems to vary:) The OP's example does not leak. It never loses track of the memory allocated to 's'. – Martin James Mar 12 '18 at 14:46

0 Answers0