<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Already filed incident #<span data-testid="issuable-reference"
        class="issuable-reference">39625</span></p>
    <p>My way to express the issue was that if you set the
      ifoWriteStringBoolean option but do not assign the string
      array(s), WriteBool will write a string to the ini file which
      ReadBool cannot correctly read back. Furthermore, since the
      ifoWriteStringBoolean  option is missing in the documentation, one
      cannot now.<br>
    </p>
    <p>IMHO, such a behavior is not intentional.</p>
    <p>Armin (aka Nimral)</p>
    <div class="moz-cite-prefix">Am 16/03/2022 um 13:04 schrieb Bart via
      fpc-devel:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMye31zF4j-Grh2U9UKVyXci4wd3vcA3CyXnBPfPXejtFtFLCA@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Hi,

User Nimral in the wiki noted this:
If you specify ifoWriteStringBoolean in Options for TIniFile _and_ you
forget to assign values to BoolTrueStrings/BoolFalseStrings, then
writing and reading boolean values is not symmetrical.
Writing a boolean will write either 'true' or 'false', but reading
calls CharToBool on the found string.

Consider this piece of code:
  Ini := TIniFile.Create('test.ini');
  Ini.Options := [ifoWriteStringBoolean]; //[ifoWriteStringBoolean]
  Ini.WriteBool('Section','True',True);
  Ini.WriteBool('Section','False',False);
  Ini.Free;

Creates an inifile like:
[Section]
True=true
False=false

Now, with the same options for TIniFile, read the booleans:
  Ini := TIniFile.Create('test.ini');
  Ini.Options := [ifoWriteStringBoolean];
  B := Ini.ReadBool('Section','True',False);
  Check(B, True); //Found FALSE, Expected TRUE: FAIL
  B := Ini.ReadBool('Section','False',True);
  Check(B, False); //Found FALSE, Expected FALSE: OK
  Ini.Free;

I would have expected that, with exactly the same options for
TIniFile, if you read from the ini what you wrote to that ini, you
would get the same value back.

To me, it would have made more sense to either:
- let WriteBool write '1' or '0' if BoolTrueStrings/BoolFalseStrings are empty
or
- let ReadBool compare to 'true' / 'false' if
BoolTrueStrings/BoolFalseStrings are empty
(
or
- initilaze BoolTrueStrings to ['1'] and BoolFalseStrings to ['0']
)

This may very well be Delphi compatible (I cannot test that nor can
find info in Delphi's DocWiki), but if it is not:
Is this by design or is it a bug?

Bart


</pre>
    </blockquote>
  </body>
</html>