Hi,
this is caused by a misuse of the second argument to the getline()
glibc function in fgetln(). The number stored there is not the number
of bytes read (plus 1), but the actually allocated size for the buffer,
which may be larger. To find the number of characters read, the
return value of getline has to be used instead.
Proposed implementation:
(glibc-bsd-glue/bsdcompat/fgetln.c)
#include "bsdcompat.h"
#include <stdlib.h>
char *
fgetln (FILE *stream, size_t *len)
{
char *line=NULL;
ssize_t slen;
*len = slen = getline (&line, len, stream);
if (slen < 0)
return NULL;
return line;
}
(end of file)
Btw, the function leaks memory, but it's no worse than before.
regards,
Bertram
P.S. on the memory leak.
BSD's fgetln() returns a buffer that is invalidated upon the next file
I/O operation on the handle. (In fact it appears to return a pointer
into libc's read buffer for the stream)
So while reusing a single buffer as follows is tempting,
char *
fgetln (FILE *stream, size_t *len)
{
static char *line = NULL;
static size_t line_size = 0;
ssize_t slen;
*len = slen = getline (&line, &line_size, stream);
if (slen < 0)
return NULL;
return line;
}
I'm not convinced that it's safe; in fact I suspect that registering
a command using rl_add_defun() which (recursively) sources another
config file will break this.
It's probably easier to fix the calling sites to use getline instead.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
