bug in assigning to dynamic array element

ketmar via Digitalmars-d digitalmars-d at puremagic.com
Sat Nov 1 05:09:44 PDT 2014


On Sat, 1 Nov 2014 12:01:04 +0000
Iain Buclaw via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On 1 November 2014 11:56, ketmar via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
> > On Sat, 01 Nov 2014 11:31:51 +0000
> > anonymous via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> >
> >> I don't know how D defines this, and I couldn't find anything but
> >> a forum discussion [1] (which I didn't read all of). But unless
> >> it's explicitly stated that the right-hand side is evaluated
> >> first, there is no bug.
> > there is. compiler generates code that modifies random memory
> > addresses. this is absolutely unacceptable. and this is just illogical
> > if we want dynamic arrays to look and work like "normal" arrays.
> > besides, it's easily fixable without any changes in evaluation order.
> 
> I'm not *entire* sure on that. :)
> 
> If the evaluation of LHS[IDX] has a side effect, you've broken LTR.
> 
> Think:
> Left => Index => Right
> 
> vs
> 
> Index => Right => Left
p.s. besides, the following code LOOKS wrong:

  info.list[idx] = saveIt(info, count-1);
  assert(info.list[idx] != 0);

aren't it a nonsence if we know for sure that saveIt() will never
return zero? if the code *LOOKS* wrong, it is wrong. that assert()
should never fire by any logical means.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141101/fa55efa9/attachment.sig>


More information about the Digitalmars-d mailing list