[Issue 15293] [REG2.069.0] std.stdio.readln(buffer) messes up buffer's capacity

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15293

--- Comment #12 from ag0aep6g at gmail.com ---
(In reply to Steven Schveighoffer from comment #9)
> The reason it was done this way is to allow for a common usage of readln
> (namely, reading into a buffer over and over again) to continue to have good
> performance.

I understand that, and I think that goal is not compatible with having sane
behavior. In my opinion, calling assumeSafeAppend on a smaller slice is not
acceptable when larger slices may exist in the outside world.

> If we took the "safe" route (and believe me, it was debated and
> considered), then this code would reallocate every time a larger line was
> read. When it was originally written, this is what byLine did, but now it's
> changed.
> 
> > The other readlnImpl variants don't work like that
> 
> looking at it now, the other variants do exactly as I said above -- they
> reallocate when the line is longer.

Which is simply the right thing to do. With the API of readln I think we just
have to accept the allocations.

> So technically we could move to this, we just have to accept a drop in
> performance for the code.
> 
> Have you tested the performance of your new code vs. the current
> implementation?

No. I'm sure there is going to be a performance drop. I don't think that it
matters, though. Correctness beats speed.

It also only affects naive readln calls on Windows. byLine is already cautious
about what exactly it gives readln as a buffer, so it shouldn't get slower. And
on other OSs readnl already does the excessive allocations.

--