Hi All,

This does not work:

  TConfiguration = record
    DataFolder: string[MaxPathLen];
  end

Error: string length must be a value from 1 to 255

I already have this on the top of my uinit file: {$mode objfpc}{$H+}{$LONGSTRINGS ON}

Working with Lazarus 1.0.6/FPC2.6.0 on Linux 3.5/x86_64

Any hint please? Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/69f19f3a/attachment.html>

The "String[...]" declaration always declares a ShortString and those can have only 1 to 255 characters. An AnsiString does not need the "[...]", because it has always variable length.

Side note: {$H+} and {$LONGSTRINGS ON} is redundant, both mean the same (though {$H+} is more commonly used).

Regards,
Sven

Ok, My purpose is to write the record into stream, so I cannot use variable length. Now I use an array [0..MaxPathLen] of Char.

2013/3/3 Sven Barth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/113d1a0c/attachment.html>

Xiangrong Fang wrote

Ok, My purpose is to write the record into stream, so I cannot use variable length. Now I use an array [0..MaxPathLen] of Char.

If you want to write a complete record to stream (and not write it's elements manually) you should declare your record as "packed" as only then the records are guaranteed to be the same on different plattforms (with the exception of different endianess).

E.g.

=== code begin ===

type
   TConfiguration = packed record
     //
   end;

=== code end ===

See also here: http://community.freepascal.org/docs-html/ref/refsu15.html

Regards,
Sven

Hi Sven,

{$mode objfpc}{$H+}
  TConfiguration = packed record
      DataFolder: string;
  end;

does not work, but:

  TConfiguration = packed record
      DataFolder: array [0..MaxPathLen] of Char;
  end;

worked. My save procedure is:

function SaveParams(var Buffer; Count: Integer; FileName: string): Boolean;
var
  fs: TFileStream;
begin
  Result := False;
  if not ForceDirectories(ExtractFilePath(FileName)) then Exit;
  try
    fs := TFileStream.Create(FileName, fmCreate);
    try
      fs.Write(Buffer, Count);
      Result := True;
    finally
      fs.Free;
    end;
  except
  end;
end;

It is called on the finalization section of config.pas:

SaveParams(cfg, SizeOf(cfg), cfn);
//cfg is TConfgiruation, cfn is the filename.

The symptoms of error are:
1. The DataFolder value is not saved to configuration file, although file saving seems succeeded.
2. There are weird access violations, e.g. on exiting or on occasions that I try to manipulate the configuration at runtime (RunError(203) was reported).

Anything that I did wrong? or, AnsiString is not supported this way anyway?

2013/3/3 Sven Barth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/5a709c84/attachment.html>

A (Ansi)string in {$H+} mode is just a pointer (to the characters of the string). So sizeof(DataFolder)=4 (or 8) in all cases. There is no room for the string unless you configure it with SetLength(DataFolder,MaxPathLen). But even then the record does not store the characters. It only stores the pointer to the string:

DataFolder = pointer
DataFolder[1] = DataFolder^[1] = first character of the string.

There is an automatic dereferenciation that allows to write DataFolder[x] although the logic would require DataFolder^[1].

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/ea16d1fa/attachment.html>

No, AnsiString is not supported in this way. As J?rgen wrote it's basically a pointer to the string data and not a static array of the string data. And the write and read procedures of TStream (but also the file I/O) will write the record's memory as is and thus the value of the pointer will be written in case of AnsiString.

Regards,
Sven

A (Ansi)string in {$H+} mode is just a pointer (to the characters of the string). So sizeof(DataFolder)=4 (or 8) in all cases. There is no room for the string unless

I guess this is the cause, but then there is no need to specify "packed" if I just use array of char.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/2b2d82b1/attachment.html>

The "packed" should always be used if you want to read/write data. Only then you can be sure that the memory layout of the record is correct. Otherwise padding bytes will be added. Consider the following record:

=== example begin ===

type
   TMyRecord = record
     b: Byte;
     i: LongInt;
     w: Word;
   end;

=== example end ===

The size of this record will be 12, because between b and i and after w padding bytes are added. While if you add "packed" the size will be 7 and the fields will directly follow after each other.

The memory layout of non-packed records is not guaranteed to stay the same between FPC versions! It could be for example that we find a bug in the code that generates the memory layout of a record and then suddenly you can no longer read in files that were written by a version of your program compiled with the older compiler. For "packed" there is the guarantee though that the layout will stay the same.

Regards,
Sven

Are you only writing strings (and/or integers and/or booleans) to the configuration file?
If so, wouldn't it be just easier to use a TIniFile for that?

Bart

I was using an INI file, but record make things a lot easier.

2013/3/3 Bart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/d5346522/attachment.html>

I was using an INI file, but record make things a lot easier.

If you use TIniFile, you don't have to worry about saving and restoring values. It's much easier than writing your own saving/restoring procedure.

Al 03/03/13 14:34, En/na Sven Barth ha escrit:

For "packed" there is the guarantee though that the layout will stay the same.

Are you sure? Does the same guarantee apply to bitpacked? Lately I've become lazy, and instead of manually decoding data (bits, bytes, words) read from a device, I'm relying on packed/bitpacked records, but I wasn't sure that upgrading the compiler wouldn't break my code.

Bye

For "packed" it is guaranteed (*), because this is the whole purpose of this modifier, for "bitpacked" it is not. It just tells the compiler to pack the record as densly as possible, but depending on the platform this might not be possible.

(*) the only exception for this is the JVM platform, because there the
file I/O mechanism of Pascal is not supported

Regards,
Sven

Al 03/03/13 21:52, En/na Sven Barth ha escrit:

At the moment I don't care about the platform, only about different (newer) versions of the compiler.
Currently , with 2.6.0, bitpacked under win32 gives me the correct layout (I have to adjust endianness for words/dwords but individual bit fields are where they should be).
Can I be sure that 2.6.2 (and later version) won't break my code?

Bye

I can only give you a guarantee for packed. For bitpacked it's documented that you shouldn't rely on the binary format.

Regards,
Sven