1

In my program, I'm declarign a character array holding the location of a config file, it should be something like: "/home/user/.config"

now I understand the longest username can be 32 bytes long(GNU Linux), so I know that array will not hold more than 46 characters, in this case should I be using malloc or not.

should I use:

char config_file_location[46];
strcpy (config_file_location, getenv("HOME"));
strcat(config_file_location,"/.config");

or:

char *config_file_location;
config_file_location = (char *) malloc(43);
strcpy (config_file_location, getenv("HOME"));
strcat(config_file_location,"/.config");
//code goes here
free(config_file_location);

also should I use realloc in the above example to get the config_file_location to use exactly the amount of memory it is supposed to?

I'm looking for best practice info, if it is not worth doing in this case, I would like to know when it would be, and I would like to know the reason behind which approach is better.

Thanks I appreciate it.

Adel Ahmed
  • 638
  • 7
  • 24
  • 2
    Are you sure the home directories always have the form `/home/username`? Don't make such assumptions. For example, my home directory is in `/export/home/fuz` and I've also had a system where my home directory was `/pub/homesrv/department/home/username`. – fuz Dec 02 '15 at 11:49
  • 1
    If you have an array you don't have to worry about memory leaks, if you have a dynamically allocated buffer you *sholdn't* have to worry about it being to small. – Some programmer dude Dec 02 '15 at 11:50
  • 1
    You "know" the longest config_file_location is 46 characters... When your code crashes, remember one of the most important rules of debugging: What you know is wrong. As @FUZxxl already told you. – gnasher729 Dec 02 '15 at 11:57
  • good point FUZxxl, I'll increaase the size to 255 then – Adel Ahmed Dec 02 '15 at 12:18

2 Answers2

2

There are two reasons why you would use dynamic allocation:

  • Either because the amount of memory needed isn't known at compile-time, or because the amount of memory needs to be reallocated in run-time.
  • Or because you need to allocate large amounts of data and don't want to burden the stack with it. Allocating too much memory on the stack can in the worst case lead to mysterious run-time crashes caused by stack overflow. To avoid this, large amounts of data should be allocated on the heap instead.

In your case, you have a fixed amount of data and 43 bytes is hardly a large amount. So there is no need to use dynamic allocation here.

Apart from the usual issues with memory leaks and heap fragmentation, you also have to consider that each call to malloc (and free) is quite time-consuming. On systems where dynamic allocation is feasible (such as Linux), it almost always makes more sense to optimize for speed instead of memory consumption.

Lundin
  • 195,001
  • 40
  • 254
  • 396
2

Unless you are working in some really, really memory constrained environment, I wouldn't be worried about optimising how much memory your application uses. Just allocate a buffer on the stack that is "big enough" for the largest path you might encounter.

As to how big that is, no one is going to give you a definite answer. You could use PATH_MAX, although it has been noted even that has problems. In these situations I would just take a pragmatic approach and go for something like 256 bytes. Job done. Move on.

Community
  • 1
  • 1
PokeyBagelHole
  • 51
  • 3