title: Converting integer to binary - how it's done on Android ( vs Windows) - XE5
body: <p>So, yesterday I opened up a <a href="https://stackoverflow.com/questions/21361627/converting-decimal-integer-to-binary-how-and-why-it-works-the-way-it-does">question about converting integer to binary</a>, which was a little unclear to me, about how it works (with the shifting operations).
  Now, I have another question here to disguss: How it's done on android, why it results differently than doing it on windows, and how to get the actual binary result rather than what I get now (and about this one I'm not yet clear what it is; it's somehow hex with a wrong value).</p>
  
  <p>I have this code in a firemonkey mobile project, which has both, android and windows platforms set as targets.
  This way the code testing can be done by targeting windows, so that it compiles faster, and previews as virtual mobile form; Well, at least the intention is to do this, but looks like it's not so reliable source of errors...</p>
  
  <p>While the same project ran on Win32 worked just fine, running it on android results in not getting binary result out of a function.</p>
  
  <p>I use this code to make conversions:</p>
  
  <pre><code>function IntToBin(Value: Integer): string;
  var
    i: Integer;
  begin
    SetLength(Result, 9);
    for i := 1 to 9 do begin
      if (Value shr (9-i)) and 1 = 0 then begin
        Result[i] := '0'
      end else begin
        Result[i] := '1';
      end;
    end;
  end;
  </code></pre>
  
  <p>The debugger shows this, when trying to convert value '1':</p>
  
  <pre><code>Result: 0x6d09d738
     *Result: #0'00000000'                      [expanded from Result]
  Value: 1
  </code></pre>
  
  <p>Now, I know that the reason I'm then (after the main procedure, which calls this conversion function is completed) getting exactly the half value of what it should be (1 instead of 3, 2 instead of 4, 8 isntead of 16, 6 instead of 12...) is because in *Result there is clear that it's only 8 bit, when I need 9 bit result (I'm doing conversions from Integer (1..512) to binary...), and therefore insead of reading 2 as 0010, I get 001, which is 1, instead of 6 (0110) I get 3 (011), 8 (1000) I get 4 (100) etc....</p>
  
  <p>Now I really want to know why, at first, it even throws result as 0x6d09d738 / 0x6d09d738 instead of just binary, and why is it not 9bit, as I set the length of a result string?</p>
  
  <p>Also, here's another interesting and for me ununderstandable thing:</p>
  
  <p>This is my procedure which triggers coversion:</p>
  
  <pre><code>procedure TForm1.CalculateAddress1;
  var SetDip: string;
      C: integer;
  begin
    SetDip := IntToBin(StrToInt(MergeAddr));
    //Text1.Text:=SetDip;
    for C := 1 to 9 do
      begin
        if Copy(SetDip, b, 1) = '1' then
        DipSW[10-b].IsChecked:=True
        else DipSW[10-b].IsChecked:=False;
      end;
  end;
  </code></pre>
  
  <p>// (I use this to convert dmx address into dip switch configuration...)</p>
  
  <p>The SetDip gets something of a value like #0'00000000'. (it differs; this is the case when integer that was converted is 1; for 11 I get #0'00000101' );</p>
  
  <p>This results as having the exact half value as it should be (as I mentioned above; And I understand why this is happening, since one bit of a result is missing...).</p>
  
  <p>However, if I remove the // from <code>Text1.Text:=SetDip;</code>, which I putted there so I could see the result on the phone screen, I get the next error, on phone only! (again, targeting windows runs ok):</p>
  
  <p>'String index out of range (-1).  Must be >= 0 and &lt;= 8';</p>
  
  <p>After that, Segmentation fault is raised, 2 Access violation errors and finally, the app closes itself. </p>
  
  <p>It looks like it can't copy SetDip to Text1.Text field; That's what I thought. But later I found out that this error doesn't occur always, which was weird, since it should, and not just that: it should even when I leave Text1.Text:=SetDip out of code;  -> I don't know how it copyes string at index 9, if it's not that long; I know this is exactly the reason it throws the error, but again: why not always?</p>
  
  <p>[[ Ps: +, found out that Firemonkey handles fixed arrays automatically, if the code tries to create entry beyond the defined size. Interesting... :)  Maybe this means that it handles the string length and copy indexes by itself too..?  ]]</p>