I have a C program I've written that includes a 'getline' call that is used to read a line at a time from a file and process the information in each line. A potential problem comes up since I don't know the maximum length of each line; right now I'm using a constant of 256, but that might not be long enough when run in the real world. The description of getline says that it will 'realloc' the string if it's not long enough, so I've tried running the program lowering the aforementioned constant to a value less than most of the lines in my input file and passing that value into 'getline' as the 2nd parameter 'n'. When I run it using the 'ddd' debugger, I get a segmentation fault after a few lines had been read on a 'free' call. I also ran it outside of 'ddd' with 'valgrind' and the program runs all the way through with no seg fault, though it says that I "definitely lost" a little over a hundred bytes, something that didn't happen before. I wonder if I should just set the char pointer to NULL and 'n' to zero and let getline do all the allocation, though passing it an already-allocated string that's not long enough should work, too, according to the man page. I'm also unclear about the purpose of the 'n' parameter and what the value is that's returned there; it returns the number of bytes read, but not through that parameter. Any words of wisdom would be appreciated.

Kinda hard to tell why its segfaulting without seeing any code. Make sure you are passing a **buf not a *buf.

But as far as the 'n' parameter its there so you can pass in the size of the buffer that you pre-allocated. It will contain the size of the buffer you get back. Thus if you passed in a buffer too small it will have the new size. If you passed in null, it will have the size that was allocated for it.

The return value of the function returns characters read (not necessarily size of the buffer) not counting the last null byte if there.

Thanks for the reply. I think I know why the segfault happened, having to do with the logic of my program and the fact that I changed a bit of it to try giving 'getline' a smaller character string; I won't bore you with all the details.

While looping through a file, reading one line at a time, I should just need to call 'free' once, after the loop is through, correct? It's doing a 'realloc' when it needs more room, and not allocating a whole new string each time. I'm wondering about how much more space it reallocs when it's necessary. I just ran my program again checking the return value of 'n', size of buffer returned, and the value of bytes that were read (my initial value of the size of line is 25, just picking one that would be too small most of the time):

bytes read size of buffer returned
7 25
56 57
36 57
97 114
70 114
23 114
39 114

Apparently, once the buffer being passed back gets a certain size, it won't get reallocated to a smaller size, what with it staying at 114. I'm wondering why when the line was 96 bytes it didn't return a buffer of size 97 (allowing for the null) instead of jumping to 114.

Thanks again.