On 24.08.2016 20:49, Ingo Schwarze wrote: >> Yes, it is a bit problematic, but it is the way this function >> designed in BSD 44lite, so I disagree with the patch. >> I.e. preserving partial line is more essential for it than >> returning no line at all (NULL), so tail error on partial line >> is not treated as error. > > Do you really think anybody depends on getting a partial line back > right before a low-level read error? Even though it works only > sometimes, not always, almost always returns incomplete data, and > the point where the data will be cut off is almost unpredictable?
I don't think so. I just explain for you this function design intentions comes from early 44lite days when error handling was not essential comparing to data preserving. And if we plan to change original 44lite function behavior, all BSD camps should agree at least. >> Since this function usually used in the loop, it returns partial >> line on the first pass and returns NULL with error on the second >> pass, so uncatched error on the first pass is not a big deal. > > I agree that it's not a big deal for *this* function (only a minibug > as i said). In particular because for byte-oriented streams, it > is an uncommon situation that you can read some bytes but then run > into a read error. > > But i'd like to get both getln(3) and getwln(3) fixed, and both of > them in a similar way. And for getwln(3), the situation of being > able to read some wide characters before running into an (encoding) > error is not uncommon at all, and in that case, you noticed yourself > that the *next* read will typically not fail again, so the typical > loop will treat the encoding error as a newline, put the library > into an undefined shift state, and happily go on to read garbage. Could you show some code? In my testing fgetwln() fails on next read if previously there was partial line with tail EILSEQ. Stdio not advance its pointer over the sequence with EILSEQ. > Actually, even in getln(3), this can go quite wrong in the form of > a race condition - for example, a program running with input connected > to a terminal using SIG_IGN on SIGTTIN. Imagine the first read > fails with EIO, then the program comes back to the foreground, and > by the time of the next read, that read succeeds again. So some > data is lost, but the temporary error looks exactly like a newline > (unless somebody checks ferror(3) after a successful read, which > isn't very reasonable to do). I don't know from where you got this newline idea. 1) if those functions goes so far to return newline, it means they meet no errors at all. 2) If the last character is not newline, it means (W)EOF or error.
