Re: [fpc-pascal] more questions on storage
On Wed, 26 Sep 2007, Marc Santhoff wrote:
Hi,
having this definition:
{$mode objfpc}
{$longstrings on}
type
cmpstr = record
ID: integer;
Name: string;
Value: single;
end;
var
buf: array [0..MAX] of cmpstr;
How does the memory layout of the buffer look like?
I tried to get there with ddd but I couln't find out how the string
inbetween is put into memory. For atomic types (integer, single) it's
pretty clear, but longstrings do have a variable size. How is the buffer
set up?
Longstrings are not working correctly. You should use ansistrings or
shortstrings.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc 2.2.0 win32_arm-linux cross-compiler issue
Hi all, I have downloaded the freepascal 2.2.0 fpc source code ( fpcbuild-2.2.0.zip) and attempted to create a arm-linux cross-compiler that runs under win32. I have done this previously with the fpcbuild-2.0.4 .zip file ok using this batch file: **START OF BATCH FILE set path=G:\fpc\2.2.0\bin\i386-win32 make distclean make all install CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=G:\fpc-crossbinutils\arm-linux BINUTILSPREFIX=arm-linux- INSTALL_PREFIX=G:\fpc_win32_arm-linux COMPILER_OPTIONS=cpufpemu pause END OF BATCH FILE** After I build the cross-compiler and tried using 'ppcrossarm.exe' to build a pascal program I was having errors in the output and noticed this: Free Pascal Compiler version 2.2.0 [2007/09/24] for arm Copyright (c) 1993-2007 by Florian Klaempfl Target OS: WinCE for ARM I am using the same batch file to compile my pascal program that I used before so I am unsure why it is saying that the Target OS: WinCE for ARM is coming up :( cheers, Paul ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 09:30 +0200 schrieb Michael Van Canneyt:
On Wed, 26 Sep 2007, Marc Santhoff wrote:
Hi,
having this definition:
{$mode objfpc}
{$longstrings on}
type
cmpstr = record
ID: integer;
Name: string;
Value: single;
end;
var
buf: array [0..MAX] of cmpstr;
How does the memory layout of the buffer look like?
I tried to get there with ddd but I couln't find out how the string
inbetween is put into memory. For atomic types (integer, single) it's
pretty clear, but longstrings do have a variable size. How is the buffer
set up?
Longstrings are not working correctly. You should use ansistrings or
shortstrings.
Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not
working?
And back to the original question: how is the memory layout using
AnsiString then?
Thanks,
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
set up? Longstrings are not working correctly. You should use ansistrings or shortstrings. Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not working? And back to the original question: how is the memory layout using AnsiString then? The field is a pointer to the ansistring. Which is basically a pchar with a TAnsirec record on negative offset of the ptr value. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On 26 Sep 2007, at 11:18, Marc Santhoff wrote: Longstrings are not working correctly. You should use ansistrings or shortstrings. Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not working? Longstrings were never completely implemented nor tested, so no one really knows what works and what doesn't. It would be better if the compiler simply gave an error for them at compile time. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 11:38 +0200 schrieb Jonas Maebe:
On 26 Sep 2007, at 11:18, Marc Santhoff wrote:
Longstrings are not working correctly. You should use ansistrings or
shortstrings.
Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not
working?
Longstrings were never completely implemented nor tested, so no one
really knows what works and what doesn't. It would be better if the
compiler simply gave an error for them at compile time.
That's irritating, because rtl.pdf from the 2.0.4 release says on page
19:
1.1.20 $H or $LONGSTRINGS : Use AnsiStrings
If {$LONGSTRINGS ON} is specified, the keyword String (no length
specifier) will be treated
as AnsiString, and the compiler will treat the corresponding variable as
an ansistring, and will
generate corresponding code.
I read it as there is no difference between the two (in that release)
and the compiler switches can be exchanged.
FWIW, I have this sitch in a couple of source files for a while now and
never had any (noticable) problems.
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 11:34 +0200 schrieb Marco van de Voort: set up? Longstrings are not working correctly. You should use ansistrings or shortstrings. Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not working? And back to the original question: how is the memory layout using AnsiString then? The field is a pointer to the ansistring. Which is basically a pchar with a TAnsirec record on negative offset of the ptr value. Thanks, that's what I assumed and could not proof. Is this the case for any occurences of AnsiString, the type name itself is a pointer behind the scenes or only in this special case of an array (would make less sense)? Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 11:34 +0200 schrieb Marco van de Voort: The field is a pointer to the ansistring. Which is basically a pchar with a TAnsirec record on negative offset of the ptr value. Thanks, that's what I assumed and could not proof. Is this the case for any occurences of AnsiString, the type name itself is a pointer behind the scenes or only in this special case of an array (would make less sense)? In general, and can be nil when empty. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc 2.2.0 win32_arm-linux cross-compiler issue
Hi all, I have downloaded the freepascal 2.2.0 fpc source code ( fpcbuild-2.2.0.zip) and attempted to create a arm-linux cross-compiler that runs under win32. I have done this previously with the fpcbuild-2.0.4 .zip file ok using this batch file: **START OF BATCH FILE set path=G:\fpc\2.2.0\bin\i386-win32 make distclean make all install CPU_TARGET=arm OS_TARGET=linux CROSSBINDIR=G:\fpc-crossbinutils\arm-linux BINUTILSPREFIX=arm-linux- INSTALL_PREFIX=G:\fpc_win32_arm-linux COMPILER_OPTIONS=cpufpemu pause END OF BATCH FILE** After I build the cross-compiler and tried using 'ppcrossarm.exe' to build a pascal program I was having errors in the output and noticed this: Free Pascal Compiler version 2.2.0 [2007/09/24] for arm Copyright (c) 1993-2007 by Florian Klaempfl Target OS: WinCE for ARM I am using the same batch file to compile my pascal program that I used before so I am unsure why it is saying that the Target OS: WinCE for ARM is coming up :( WinCE is the default ARM target if a cross compiler is build under Windows. You need to specify -Tlinux on the commandline or add it to fpc.cfg to make it the default: #ifdef cpuarm -Tlinux #endif ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
Longstrings were never completely implemented nor tested, so no one
really knows what works and what doesn't. It would be better if the
compiler simply gave an error for them at compile time.
That's irritating, because rtl.pdf from the 2.0.4 release says on
page
19:
1.1.20 $H or $LONGSTRINGS : Use AnsiStrings
If {$LONGSTRINGS ON} is specified, the keyword String (no length
specifier) will be treated
as AnsiString, and the compiler will treat the corresponding
variable as
an ansistring, and will
generate corresponding code.
I read it as there is no difference between the two (in that release)
and the compiler switches can be exchanged.
It seems there's some confusion in terminology. {$longstrings on}
maps to {$h+}, which indeed means that string becomes an alias for
ansistring rather than for shortstring. Separately from that there is
also a type called longstring which is basically a shortstring but
with a 4 byte length field. It's this longstring which has not been
implemented properly.
Ansistrings (and thus {$longstrings on}) work fine.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On 26 Sep 2007, at 12:03, Marco van de Voort wrote: Am Mittwoch, den 26.09.2007, 11:34 +0200 schrieb Marco van de Voort: The field is a pointer to the ansistring. Which is basically a pchar with a TAnsirec record on negative offset of the ptr value. Thanks, that's what I assumed and could not proof. Is this the case for any occurences of AnsiString, the type name itself is a pointer behind the scenes or only in this special case of an array (would make less sense)? In general, and can be nil when empty. And it's reference counted, so any record containing an ansistring has initialization rtti (and when declaring a record of this type, or allocating memory for it using new(), the compiler initialises the ansistring fields with nil). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 12:55 +0200 schrieb Jonas Maebe:
On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
Longstrings were never completely implemented nor tested, so no one
really knows what works and what doesn't. It would be better if the
compiler simply gave an error for them at compile time.
That's irritating, because rtl.pdf from the 2.0.4 release says on
page
19:
1.1.20 $H or $LONGSTRINGS : Use AnsiStrings
If {$LONGSTRINGS ON} is specified, the keyword String (no length
specifier) will be treated
as AnsiString, and the compiler will treat the corresponding
variable as
an ansistring, and will
generate corresponding code.
I read it as there is no difference between the two (in that release)
and the compiler switches can be exchanged.
It seems there's some confusion in terminology. {$longstrings on}
maps to {$h+}, which indeed means that string becomes an alias for
ansistring rather than for shortstring. Separately from that there is
also a type called longstring which is basically a shortstring but
with a 4 byte length field. It's this longstring which has not been
implemented properly.
Ansistrings (and thus {$longstrings on}) work fine.
Ah, okay. The Fog is lifting fastly. :)
And AnsiStrings are pretty much compatible to C's char*. Very handy.
Many thanks,
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
ansistring rather than for shortstring. Separately from that there is
also a type called longstring which is basically a shortstring but
with a 4 byte length field. It's this longstring which has not been
implemented properly.
Ansistrings (and thus {$longstrings on}) work fine.
Ah, okay. The Fog is lifting fastly. :)
And AnsiStrings are pretty much compatible to C's char*. Very handy.
Yes, though ansistrings may contain #0's.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 13:24 +0200 schrieb Marco van de Voort:
On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
ansistring rather than for shortstring. Separately from that there is
also a type called longstring which is basically a shortstring but
with a 4 byte length field. It's this longstring which has not been
implemented properly.
Ansistrings (and thus {$longstrings on}) work fine.
Ah, okay. The Fog is lifting fastly. :)
And AnsiStrings are pretty much compatible to C's char*. Very handy.
Yes, though ansistrings may contain #0's.
Interesting, how will a cast handle this case?
Will it change the intermediate #0 to something else or will the
resulting pchars be cut at first occurrence?
I'd never use #0 in the middle of a string myself, but to be sure if a
user manages to do so ...
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
On 26 Sep 2007, at 15:12, Marc Santhoff wrote: And AnsiStrings are pretty much compatible to C's char*. Very handy. Yes, though ansistrings may contain #0's. Interesting, how will a cast handle this case? Will it change the intermediate #0 to something else or will the resulting pchars be cut at first occurrence? You just get a pointer to the string data as-is, without any substitutions or pointer juggling. If whatever you pass the data to interprets #0 as the end of the string, it will see that embedded #0 as the end of the string. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] more questions on storage
Am Mittwoch, den 26.09.2007, 13:24 +0200 schrieb Marco van de Voort:
Ansistrings (and thus {$longstrings on}) work fine.
Ah, okay. The Fog is lifting fastly. :)
And AnsiStrings are pretty much compatible to C's char*. Very handy.
Yes, though ansistrings may contain #0's.
Interesting, how will a cast handle this case?
Will it change the intermediate #0 to something else or will the
resulting pchars be cut at first occurrence?
A cast is really a cast. IOW the cast pchar(ansistring) is mostly a no-op.
Traditional C code then usually treats the #0 as end of string.
It's mostly important when ansisstring is abused as general purpose buffer,
but generally it is better to use dyn arrays for that.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
