"Walter Bright" <newshou...@digitalmars.com> wrote in message news:hdqea8$2mt...@digitalmars.com... > Bartosz Milewski wrote: >> I read Andrei's chapter on arrays and there's one thing that concerns >> me. When a slice is extended, the decision to re-allocate, and >> therefore to cut its connection to other slices, is >> non-deterministic. > > It is not non-deterministic. Try it - you'll get the same results every > time. It is implementation-defined behavior. > > >> How does that influence program testing and can it >> be exploited to attack a buggy system? > > Exploitations rely on undefined-behavior, such as buffer overflows, not > implementation-defined behavior. This issue is no more conducive to an > "exploit" than any other garden variety programming issue. It's entirely > different than a buffer overflow attack.
Definition used by Implementation "Foo": "Resize if there's room, otherwise reallocate" (sounds fairly realistic to me) Code in program using Implementation "Foo": myArrayOnHeap ~= getUserInput(); Resizes or Reallocates?: Deterministically dependant on "Is there room?" which is deterministically dependant on two things: 1. The size of the user input (non-deterministic). 2. The amount of freespace after the current end of myArrayOnHeap (dependent on the specific actions of the GC, which in turn, is dependent on other behaviors of the program, which, for almost any useful program, are dependent on non-deterministic runtime conditions, such as other user input). If 'A' ("resize or reallocate?") is deterministically determined by 'B', and 'B' ("is there room?") is non-deterministic ("dependent on things like user input"), then 'A' is, in effect, non-deterministic. Simplified example of the same basic principle in action: void main(char[][] args) { if(args.length < 10) showPrettyPicture(); else blowUpEarth(); } Deterministic? Only in the same sense that "resize or realloc upon appending" is deterministic. Safe? Fuck no.