Bruno Haible <bruno <at> clisp.org> writes: > 3. At least one byte is read, but not stored (due to nmax), and no error. > Return value was 0 and is now -1.
You are right that the program can usefully distinguish between -1 and 0 here (with getdelim, there is no nmax parameter, hence getdelim can never return 0). > > 4. EOF when reading the first byte, no error, and offset > 0. > Return value was 0 and is now -1. I still think this case is like getdelim failing at EOF, particularly since... > > 5. EOF when reading the first byte, no error, and offset == 0. > Return value is -1. offset should not need to be consulted if the stream is already at EOF. > > The change in cases 3 and 4 > - is IMO not appropriate, since the inability to _extend_ the current > line (due to nmax or EOF) does not mean that the part of the line that > was read so far should be ignored, > - should have been mentioned in NEWS as a behaviour change of getndelim, > - cannot be justified by pointing to getdelim in POSIX, because getdelim > does not have the nmax and offset arguments. > > I am in favour of reverting this change, and adding comments to clarify the > 5 possible outcomes of getndelim2. Yes, we can revert this part of the patch, and improve the documentation. It also means we need to beef up the testcase to stress all 5 conditions, and ensure we don't regress from the more-heavily documented interface. -- Eric Blake
