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

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Thu Nov 12 06:49:31 PST 2015


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

Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy at yahoo.com

--- Comment #7 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to ag0aep6g from comment #5)
>     writeln(line.capacity); /* "0" */
>     writeln(line[0 .. 1].capacity); /* "255" -- nonsense */

Not nonsense.

When you are passing in empty buffer, it is allocated to 256 bytes with a
capacity of 255.

The second call is given a buffer which readln can see that it has full control
over (it has capacity, which means all data after it is unused). Since passing
a buffer into readln disowns the data (readln now owns and can resize the used
portion down if necessary), the error is continuing to use 'buffer' as the
buffer -- buffer contains 2 bytes, the second byte is essentially garbage after
assumeSafeAppend is called since it's not part of the capacity. readln is meant
to be passed in the same buffer over and over, this is why it uses
assumeSafeAppend.

Doing that, the final readln call sees that it has no capacity, so it treats
this as an un-extendable buffer. It can't resize the buffer, nor claim that
some of the buffer space is now usable (if the full line fits in less bytes).
Basically, it treats this like a stack buffer.

On the last read, the line is shorter, but assumeSafeAppend isn't called
because it doesn't know where the buffer comes from!

> This reminds me more and more of issue 13856.

That issue was fixed by the addition of the ReadlnAppender.

Also, I'll note that on my test of using dmd 2.069.0 or 2.069.1 on Macos X, I
do not get an error with the first reduction, or HeiHon's additional issue. The
changes you have in your pull are not windows specific, so I'm not sure if they
are required to fix this issue.

--


More information about the Digitalmars-d-bugs mailing list