Re: [GRASS-dev] Right way to use G_getl2

2013-09-14 Thread Markus Metz
Glynn Clements wrote: FWIW, I suggest changing the existing behaviour [of G_getl2()] so that it always reads an entire line, even if it can't store it all. IOW, read until EOL or EOF, stop storing characters once the buffer is full. +1 Unlike with fgets(), which stores the line terminator

Re: [GRASS-dev] Right way to use G_getl2

2013-09-13 Thread Markus Metz
I think the confusion arises because G_getl2(char *buf, int n, FILE * fd) reads in at most n - 1 characters, not n characters. The next character is always set to '\0' and guaranteed to be at most the n-th character. That also means that G_getl() does not check if the buffer is large enough to

Re: [GRASS-dev] Right way to use G_getl2

2013-09-13 Thread Hamish
Markus Metz wrote: I would suggest to modify G_getl2() to read at most n (not n - 1) characters and include a check if the buffer is long enough: mmmph, to me G_get2() does the right thing, as long as people follow the given instructions all is fine. So I'd vote to keep it as-is. FWIW, at

Re: [GRASS-dev] Right way to use G_getl2

2013-09-13 Thread Glynn Clements
Vaclav Petras wrote: So, finally: What is the right usage of G_getl2? Should the caller use buffer size equal to maximum number of expected characters on line plus end of line character (plus 2 on MS Windows) plus terminating character? Or should he just pass the n parameter increased by one

[GRASS-dev] Right way to use G_getl2

2013-09-12 Thread Vaclav Petras
Hi, this relates to the recent fix for r.in.ascii (r57649). The skip parameter [2] required one line more because when reading lines using G_getl2 [3] function and counting these lines it counted one line more. The documentation of the function says that it reads max n-1 bytes. In other words, n