<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/28/2014 08:58 PM, Lag Programming
      wrote:<br>
    </div>
    <blockquote
      cite="mid:8D1A95CEC2AF913-E18-26E94@webmail-vm160.sysops.aol.com"
      type="cite"><font color="black" face="arial" size="2"><font
          size="2">@Nikolay<br>
             Thank you for your answer. :) Now that you've answered, can
          you further respond to the following question: why is it
          needed to zero fill the memory allocated that exceeds the
          requested value?<br>
          a) "pointer:=allocmem(initialsize);
          reallocmem(pointer,increasedsize);". I don't see the benefits
          of the zero filled bytes that exceed the "initialsize" value
          at "pointer". Once you "reallocmem" to increase size you don't
          expect to have the additional space filled with zeros. This
          means that an attempt to somehow optimize code because of
          initial more than enough zero filling is something hard to
          believe in.<br>
        </font></font></blockquote>
    To be honest, I don't know. It's probably for some extra safety,
    e.g. to minimize the damage from the undefined behaviour of reading
    beyond the memory block you allocated or to be able to detect heap
    corruption if you overwrite these zeros.<br>
    <blockquote
      cite="mid:8D1A95CEC2AF913-E18-26E94@webmail-vm160.sysops.aol.com"
      type="cite"><font color="black" face="arial" size="2"><font
          size="2">
          b) if your affirmation is right then for "</font><font
          size="2">bytepointer:=allocmem(sizeof(byte));" we would zero
          fill at least 3 or 7 times the necessary amount. At the moment
          I don't see nothing good at that. The closest thing that got
          into my mind was the arrays. For an unknown reason to me,
          yet(somebody please enlighten me) dynamic arrays are always
          zero filled. But even these arrays don't use allocmem. It was
          something that got me curious. Instead of allocmem,
          getmem&fillchar are used separately :) (see dynarr.inc
          fpc_dynarray_setlength). Somebody saw the bottleneck(waste,
          whatever you want to call it) with this allocmem situation.</font><br>
        <font size="2">   So. Can you please further develop you answer
          according to this message.</font><br>
      </font></blockquote>
    <br>
    I seriously doubt it makes any difference on 32-bit and 64-bit
    architectures. AFAIK, on a modern CPU, it takes exactly the same
    amount of time to write 32-bits to a 32-bit aligned address as to
    write a single byte. But the extra call to MemSize probably does add
    some extra overhead, yes. As for why are dynarrays zero filled, I
    can only guess, but these things come to mind:<br>
    <br>
    1) delphi compatibility<br>
    2) zero filling ensures that magic reference counted types like
    ansistrings, interfaces and other dynarrays are properly
    initialized. The same reason class instances are initialized with
    zeros before the constructor is called.<br>
    <br>
    Nikolay<br>
  </body>
</html>