Re: getline & getline_safe
Bruno Haible <[email protected]>
| Newsgroups | gmane.comp.lib.gnulib.bugs,gmane.comp.version-control.cvs.bugs |
|---|---|
| Message-ID | <[email protected]> |
Hi Derek, Sorry that I ignored your patch with title 01-getnline.diff: it (and the followup by Steve McIntyre) didn't reach my mailbox, due to a power failure at my mail host on Wednesday. I've very sorry about it, that's not the way I use to work :-( > > The way I've done it now, programs which need both getline() and > > getnline() > > will end up with two copies of the same code, on non-glibc systems. OTOH, > > if you do it differently, you end up with getnline() code on glibc > > systems, for programs which only need getline(). The latter seems worse > > to me. > > On the contrary, you would only end up with both functions on non-glibc > systems the way I wrote the code. Anyway: the important case to consider are packages which use getline() or getnline() but not both. They should not be penalized. > I merged my changes, carried through some of > yours, and fixed a few bugs in my original patch which also existed in > yours Thanks for this work! > I also installed getndelim2 as a separate module since Jim Meyering > requested it. Yes, when we removed getstr() a few months ago, we weren't aware that coreutils/src/cut.c was using it. > Oh, I also switched limit to be a limit on the number of characters to > read rather than the amount of memory to allocate. This is broken, because it means that getnline() simulates a delimiter where none was seen. In other words, the next call to getline() will return the _remainder_ of the first long line of text, instead of the second line. For line-oriented protocols this is just broken. (Assume that in a mail I write "foobar...[many chars] From: fakedsender" and you interpret this "From: " as being the beginning of a new mail. Just broken. OK, throwing away the tail of a long line is also broken. But not as much as pretending that a newline was present when there was none. > It is easy enough > for the caller to determine limit from linesize if her intentions are to > limit memory I don't follow you here. getnline() is designed to do all it needs. The caller will do no additional checking before or after the call. Bruno