std.digest toHexString

[H. S. Teoh via Digitalmars-d-learn]

On Thu, Mar 16, 2017 at 06:41:40PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Thursday, 16 March 2017 at 18:10:43 UTC, H. S. Teoh wrote:
> > But in that case, wouldn't that mean implicit slicing isn't to blame
> > here? (Not that I'm arguing for implicit slicing -- I think it needs
> > to go, too, having been bitten by it before -- but this particular
> > case wouldn't constitute as evidence against it.)
> 
> The implicit slicing is still bug prone, just dip1000 catches it
> before it snowballs. That's a good thing, dip1000 puts an additional
> wall between the termites and the wood, but the termites do remain.

Actually, https://issues.dlang.org/show_bug.cgi?id=12625 shows that
implicit slicing is still a problem:

	char[16] func() { ... }
	void gunk() {
		string s = func(); // implicit slice

		... // do some stuff that uses the stack

		// since func's return value is a temporary, it has gone
		// out of scope here, and there is no guarantee it
		// hasn't already been overwritten by this point, right
		// inside gunk's body!  So s may already have corrupted
		// data.
	}

The problem is that func's return value is an rvalue, so slicing it
means we're already escaping a reference to data that's going out of
scope (by the end of the expression). It's no different from trying to
take the address of an rvalue.

Seems this isn't caught by -dip1000, though from what I understand of
DIP 1000, this *should* have been rejected.


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth