Re: [fpc-devel] String and UnicodeString and UTF8Stringt
Am 12.01.2011 07:16, schrieb LacaK: P.S. I still does not understand, how can things work correctly if LCL expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does not strictly follow this (at least in Windows) ? LCL uses SysToUTF8 and UTF8ToSys if it uses the RTL (and the FCL). This is often done with wrappers that wrap the RTL method and do the conversion (e.g. FileExistsUTF8, etc.). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
Am 12.01.2011 08:00, schrieb Paul Ishenin: 12.01.2011 13:54, kingbiz...@gmail.com пишет: Well guys, thanks for replying, the generic method is a very nice method, I personally didn't know that the FPC support it, very thank you for that! FPC does not support it at the moment. I hope it will in a month. Oh wow O.o That's why I love Free Pascal... Btw: Do you plan to implement constraints as well? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
12.01.2011 15:20, Sven Barth wrote: Btw: Do you plan to implement constraints as well? I thought to implement all what delphi has but I don't know whether I will be able to. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
Sven Barth wrote / napísal(a): Am 12.01.2011 07:16, schrieb LacaK: P.S. I still does not understand, how can things work correctly if LCL expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does not strictly follow this (at least in Windows) ? LCL uses SysToUTF8 and UTF8ToSys if it uses the RTL (and the FCL). This is often done with wrappers that wrap the RTL method and do the conversion (e.g. FileExistsUTF8, etc.). As I wrote in any of my previous message, AFAIK this is not true in case of fcl-db and Lazarus data-aware components like TDBGrid, TDBEdit ... They use TField.Text: String property to get string conent of field and display them. AFAIU LCL expects, that TField.Text will always return UTF-8 encoded string (because no conversion (SysToUTF8) is done in dbgrids.pas or dbedit.inc) , but this is not true always. So where is error ? 1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string -or- 2. Is it wrong in implementation of TSQLConnectors, which write data into record buffer (of TStringField) and do not convert them always into UTF-8 ? (if data should be always in UTF-8 then it will be good redefine TField.Text property like property Text: UTF8String to be clear, that we always work with UTF-8 strings) -or 3. I missed something ? ;-) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
On 01/11/2011 05:50 PM, Hans-Peter Diettrich wrote: Since the generic Delphi string type can be any Unicode encoding now, This From what O read I understand that the dynamically code string type can hold 1, 2, and 4 byte (maybe even more) Codes for it's elements (denoted in one control-value) and each of those (theoretically) in different coding schemes (denoted in another control-value), allowing e.g. for UTF-8, UTF-16, UCS4, German ANSI, raw Byte, string is what I (not owning a Delphi 2007) thought, too, and have been bashed for. But The document Delphi and Unicode by Marco Cantu ( http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf ), dated Nov, 2008, in fact states: length, the second element is the reference count. In Delphi 2009 the representation for reference-counted strings becomes: -12-10 -8-4 String reference address Code pageElem sizeRef countlength First char of string Beside the length and reference count, the new fields represent the element size and the code page. While the element size is used to discriminate between AnsiString and UnicodeString, the code page makes sense in particular for the AnsiString type (as it works in Delphi 2009), as the UnicodeString type has the fixed code page 1200. A corresponding support data structure is declared in the implementation section of System unit as: type PStrRec = ^StrRec; StrRec = packed record codePage: Word; elemSize: Word; refCnt: Longint; length: Longint; end; But maybe the document is outdated. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] String and UnicodeString and UTF8Stringt
Hello FPC, Wednesday, January 12, 2011, 9:45:47 AM, you wrote: L 2. Is it wrong in implementation of TSQLConnectors, which write data L into record buffer (of TStringField) and do not convert them always into L UTF-8 ? Do you set the CHARSET field in your TSQLConnector to UTF-8 ? Do you define the right code page in each field of your database ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variables declaraction inside code
12.01.2011 14:15, kingbiz...@gmail.com wrote: Something that I always thought very nice on other languages is the possible of adding variables inside the codes, I'm very happy using the FPC but came on my mind, FPC is always getting better and better (I first saw it like 2 years ago and I am impressed with its progress), would it on the future be possible? Declaring variables after the begin? /*Just random thoughts*/ This was discussed few times here. Later ppl tired from the endless discussions and summarised their ideas on this page: http://wiki.lazarus.freepascal.org/Modernised_Pascal Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variables declaraction inside code
On Wed, 12 Jan 2011, Paul Ishenin wrote: 12.01.2011 14:15, kingbiz...@gmail.com wrote: Something that I always thought very nice on other languages is the possible of adding variables inside the codes, I'm very happy using the FPC but came on my mind, FPC is always getting better and better (I first saw it like 2 years ago and I am impressed with its progress), would it on the future be possible? Declaring variables after the begin? /*Just random thoughts*/ This was discussed few times here. Later ppl tired from the endless discussions and summarised their ideas on this page: http://wiki.lazarus.freepascal.org/Modernised_Pascal I'm pretty sure that this abomination will be vetoed. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
On 01/11/2011 05:19 PM, Hans-Peter Diettrich wrote: IMO a single encoding, i.e. UTF-8, can cover all cases. Of course you are right here, but there are some things to be considered: In Windows (and maybe elsewhere, too) a two-Byte API (e.g. UTF-16) needs to be used, forcing lots of conversions when doing GUI applications. _All_ beginners will use s[i] and expect to get a character without any afterthought. They will be very disappointed when not using English if they get bytes instead of characters. The count of the frustrated will be much smaller (but Zero) when doing Widestring/Widechar and they get Words instead of Characters. Eliminating the s[i] syntax would trash a lot of legacy code and the decent replacement (finding the correct character and moving it into a DWord in UCS4) is slow and still does not handle all the funny Unicode character-combining stuff. But the count of frustrated beginners might be further reduced. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Am 12.01.2011 06:29, schrieb Jeppe Johansen: What do you think about this proposal? Is the current solution of using procedure variables so bad? Or what does it lack? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Den 12-01-2011 10:34, Florian Klaempfl skrev: Am 12.01.2011 06:29, schrieb Jeppe Johansen: What do you think about this proposal? Is the current solution of using procedure variables so bad? Or what does it lack? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I just think it's more elegant :) Especially on Cortex M3 devices where you usually have over 40 IRQ vector entries(84 for stm32f103). It might seem like a little much work when it's only 5 pointers. But the space required quickly grows when you also calculate the cost for initialization into it, which the new solution doesn't require ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
12.01.2011 16:34, Florian Klaempfl пишет: Is the current solution of using procedure variables so bad? Or what does it lack? I see the next benefits from WeakExternal: 1. Less accidental errors. Which procedural variables you need to care about the initial assignment to nil, then to use correct LoadLibrary handle, then you should not forget to FreeLibrary. 2. Less code to write - you don't need an initialization, finalization code. 3. Someone can accidentally reassign your procedural variable to something else. 4. I don't know exactly how this work but suspect that if your call failed because you don't have some routine in an external library then you can update the library without relaunching an application and the second call to this routine will not fail. I can be wrong regards this but as I understand this weak linking works on os level so some magic can be applied. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
L 2. Is it wrong in implementation of TSQLConnectors, which write data L into record buffer (of TStringField) and do not convert them always into L UTF-8 ? Do you set the CHARSET field in your TSQLConnector to UTF-8 ? not all connectors supports CharSet property. When I look into sources only MySQL and IB support them (SQLite always return UTF-8 encoded ... ODBC, Postgre and Oracle ignore it) Do you define the right code page in each field of your database ? Yes, this is not primary question of database side, but db client library api, which is used by SQLConnector to retrieve data. For example in ODBC we use SQLGetData in LoadField method to retrieve data from odbc interface. And for example in case of MS SQL Server character data are retrieved in current ANSI code page (in Windows of course, may be that for example in *nix data are retrieved in UTF-8 naturaly) . (AFAIK there is no universal way how to explicitly request character encoding from ODBC interface) So it is true, that every sql connector is mandatory write character data in UTF-8 ? or can write in some native format (Ansi, UTF-16) ... but in this case must somewhere write additional info about actual encoding. -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On Wednesday, 12. January 2011 09.45:47 LacaK wrote: So where is error ? 1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string -or- 2. Is it wrong in implementation of TSQLConnectors, which write data into record buffer (of TStringField) and do not convert them always into UTF-8 ? (if data should be always in UTF-8 then it will be good redefine TField.Text property like property Text: UTF8String to be clear, that we always work with UTF-8 strings) -or 3. I missed something ? ;-) MSEgui sqldb version converts to UTF-16 from/to system encoding or utf-8 (selectable by option properties) and uses FPC 16bit UnicodeString to store string field values in the dataset, the tmsestringfield returns UnicodeString values. So one can either use utf-8 encoded databaseconnections or connections with the current system encoding. MSEgui uses 16 bit UnicodeString everywhere, the conversion from/to system encoding is done transparently by the FPC unicode/widestring-manager if necessary. This is a solution which works now, no additional complicated and possibly less performant codepage and encoding aware stringtype necessary... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
On Wed, 12 Jan 2011, Paul Ishenin wrote: 12.01.2011 16:34, Florian Klaempfl пишет: Is the current solution of using procedure variables so bad? Or what does it lack? I see the next benefits from WeakExternal: 1. Less accidental errors. Which procedural variables you need to care about the initial assignment to nil, then to use correct LoadLibrary handle, then you should not forget to FreeLibrary. 2. Less code to write - you don't need an initialization, finalization code. That's not correct. You must write all the default handlers. For each procedure signature you must write a handler. So you must write more code. And if you want a correct error message at runtime, then you must write a handler per weakexternal. I am not against this feature, but this will definitely result in more code. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Tue, 2011-01-11 at 22:12 +, Martin wrote:
On 11/01/2011 21:39, Joost van der Sluis wrote:
On Tue, 2011-01-11 at 15:59 +, Martin wrote:
On 11/01/2011 09:54, Joost van der Sluis wrote:
There's a new version at that location now. This one has a better
case-sensitivity patch and support for viewing class-constants. For
those interested...
The new one crashes, when my test application is run (dwarf and dwarf 3):
I coudn't reproduce, but I had some local changes. I reverted them and
now I also have some strange results. I have no time to invest this now
any further. But maybe you can try with my local changes. (Although in
principle this shoudn't make any difference)
+ ExecuteCommand('-gdb-set case-sensitive off', []);
IT could be this line = but with it, all my other gdb versions start
failing = including the one I use to run the testcase (the one I have
configured in lazarus / 7.2-1)
That is bad news, because it seems like it that the
final-case-sensitivity solution will be that the case-sensitive flag is
used to control the behavior. But that will then break backwards
compatibility...
A solution could be that the default case-sensitivity setting is set to
'auto' by Lazarus, and that we set 'off' as the default for Pascal in
newer GDB versions, that do properly support it. I don't know if that
works, though. And I don't know what Pierre thinks of this.
But it's the same line in the error msg = so seems there is something.
The underlying problem is that a symbol is found, and then somewhere
else in the code, gdb needs some more information about the symbol. It
tries to look up the symbol, but can't find it anymore. Then you get
this assertion-problem. So it has indeed to do with the symbol-search
routines. (Which are indeed broken when case-sensitivity is set off in
unpatched versions of gdb)
Joost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variables declaraction inside code
This was discussed few times here. Later ppl tired from the endless discussions and summarised their ideas on this page: http://wiki.lazarus.freepascal.org/Modernised_Pascal Nice! For me, If I can say is most interested: 1. try ... except ... finally ... end; 2. C style IIF operator: l ? true : false; 3. C style comments: /* ... */ (I have never understood why in Pascal was used (* ... *) ) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Den 12-01-2011 11:25, michael.vancann...@wisa.be skrev: That's not correct. You must write all the default handlers. For each procedure signature you must write a handler. So you must write more code. And if you want a correct error message at runtime, then you must write a handler per weakexternal. I am not against this feature, but this will definitely result in more code. Michael. Only if you choose to use weakexternal with a set default symbol for dynamic linking. I personally don't think that's a good idea in many cases. This change doesn't require you to to set the default symbol, and if you don't it'll work like a normal weakexternal reference(eg. be nil and not warn you if it's undefined) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] String and UnicodeString and UTF8Stringt
Hello FPC, Wednesday, January 12, 2011, 11:02:00 AM, you wrote: L 2. Is it wrong in implementation of TSQLConnectors, which write data L into record buffer (of TStringField) and do not convert them always into L UTF-8 ? Do you set the CHARSET field in your TSQLConnector to UTF-8 ? L not all connectors supports CharSet property. When I look into sources L only MySQL and IB support them (SQLite always return UTF-8 encoded ... L ODBC, Postgre and Oracle ignore it) So partially it is a lack of support in TSQLConnector. Also UTF-8 in Firebird does not work as expected due a design decision (I think). L Yes, this is not primary question of database side, Oh yes it is! If you miss any of the three steps, it will fail: 1) Database field 2) SQLConnector and Client DLL/so 3) GUI L but db client library api, which is used by SQLConnector to L retrieve data. How an UTF8 SQLConnector can retrieve UTF8 data from a field defined as binary ? Client libraries have all the needed resources to handle the database, a different thing is that SQLConnector implements them and/or do it right. L For example in ODBC we use SQLGetData in LoadField L method to retrieve data from odbc interface. And for example in L case of MS SQL Server character data are retrieved in current ANSI L code page (in Windows of course, may be that for example in *nix L data are retrieved in UTF-8 naturaly) . Via ODBC ? L (AFAIK there is no universal way how to explicitly request L character encoding from ODBC interface) But that's a problem of ODBC, but: http://web.datadirect.com/resources/odbc/unicode/unix.html L So it is true, that every sql connector is mandatory write character L data in UTF-8 ? No. It is mandatory that you send/receive UTF8 to/from GUI LCL elements. In case you are using a DBF, in example which does not have encoding information, you can use the transliterate facility of dataset, but it is a bit awful. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variables declaraction inside code
On Wed, Jan 12, 2011 at 11:41, LacaK la...@zoznam.sk wrote: 3. C style comments: /* ... */ (I have never understood why in Pascal was used (* ... *) ) Because they are much more clear and easy to understand (both for compiler and for reader). C comments are very-very-very ugly. For example, you can write things like: a = b/*c; which fails if c is pointer to something. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On 12/01/2011 10:39, Joost van der Sluis wrote:
On Tue, 2011-01-11 at 22:12 +, Martin wrote:
The new one crashes, when my test application is run (dwarf and dwarf 3):
I coudn't reproduce, but I had some local changes.
+ ExecuteCommand('-gdb-set case-sensitive off', []);
IT could be this line = but with it, all my other gdb versions start
failing = including the one I use to run the testcase (the one I have
configured in lazarus / 7.2-1)
That is bad news, because it seems like it that the
final-case-sensitivity solution will be that the case-sensitive flag is
used to control the behavior. But that will then break backwards
compatibility...
The IDE can make decisions based on GDB version. So if it gets fixed
cross platform, and I know the version...
Btw, I am still trying to figure out, I've seen 3 diff notations of
version 5.2.1-1 / 7.0.50 / 7.2-50
So I can interpret either as:
Version . SubVersion [ . MinorVersion ] [ - patchlvl ]
Or
Version . SubVersion ( . | - ) patchlvl # and discard -1 in 5.2.1.-1
Alternatively, gdb could output some info somewhere, e.g in the version
string
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] += with properties
+= does work for variables, even Strings. AFAIR, there already has been a discussion about += and friends for properties. In fact I don't see why the compiler not just generates x.a := x.a + y from x.a += y before doing any code generating, disregarding what x.a is. Of course an error message will occur if x.a is not writable for any reason. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
On 12 Jan 2011, at 06:29, Jeppe Johansen wrote: While trying to find a nice solution for generating interrupt vector tables on ARM, I found that the usually employed solution is to generate weak references to symbols, that are initialized to a single handler. This way an application can override the weak reference, by declaring a new symbol with the same name. While it's possible to do that currently by using some external assembler code, I think a simpler solution could be made by using the weakexternal directive. The infrastructure is already there, but it's used in a slightly different way. How is it normally done in C? At first sight, using the weakexternal directive to /define/ symbols seems like a wrong approach. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Wed, 2011-01-12 at 11:23 +, Martin wrote: On 12/01/2011 10:39, Joost van der Sluis wrote: That is bad news, because it seems like it that the final-case-sensitivity solution will be that the case-sensitive flag is used to control the behavior. But that will then break backwards compatibility... The IDE can make decisions based on GDB version. So if it gets fixed cross platform, and I know the version... Btw, I am still trying to figure out, I've seen 3 diff notations of version 5.2.1-1 / 7.0.50 / 7.2-50 So I can interpret either as: Version . SubVersion [ . MinorVersion ] [ - patchlvl ] Or Version . SubVersion ( . | - ) patchlvl # and discard -1 in 5.2.1.-1 Well, the version I use has version 7.2.50.20110107-cvs. But those version-numbers are a mess. Especially since Fedora in fact uses a fork of gdb (Archer) but it has the same name. It's this fork I base my work on. And I don't think you can detect the difference between the forked (archer) gdb and the original one. Maybe another way to detect this is: (After an application is loaded, but you have to do this only once) set case off b MaiN - fails = old/no case-insensitive support = set case on (or auto) - works = new/working case-insensitive support = set case off Or is that too ugly? Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On 12/01/2011 11:53, Joost van der Sluis wrote: Well, the version I use has version 7.2.50.20110107-cvs. But those version-numbers are a mess. Especially since Fedora in fact uses a fork of gdb (Archer) but it has the same name. It's this fork I base my work on. And I don't think you can detect the difference between the forked (archer) gdb and the original one. Maybe another way to detect this is: (After an application is loaded, but you have to do this only once) set case off b MaiN - fails = old/no case-insensitive support = set case on (or auto) - works = new/working case-insensitive support = set case off Or is that too ugly? Maybe possible, but I would have to do it the save way, that is, the IDe needs to detect if gdb crashed, and then be able to restart, and omit... = that is some extra worrk... Or maybe, it will be enough if I just combine that with the version check too. (need to find out. Also need to see what else can be used in the version string: C:\FPC\GDB\7.2-50_joostgdb GNU gdb (GDB) 7.2.50.20101116-cvs Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. This GDB was configured as i686-pc-mingw32. Not sure what that was on fedora? Not sure if yur patched version can add something unique? Alternatively, as soon as I fix the user-config for the debugger (in the ide options) to be persistent (there is a mantis issue, so apparently it doesn't work) Then I could just add an option, and leave it to the user... What are the chances for that to be fixed in ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Offset and size of .note.GNU-stack section in object files
Hi all,
When working on bug 16545, I needed some reference so I did a 'readelf
-S' on a random .o file created by fpc.
I saw that the offset of the section behind the .note.GNU-stack section
has it's offset increased by one in comparison to the offset of
the .note.GNU-stack section. But the length of this section is 0, so
there shouldn't be an increase in the offset?
Am I right, or do I miss something?
The readelf-output of avl-tree.o, note the offsets of 4ad7 and
4ad8:
There are 12 section headers, starting at offset 0x6650:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
23a0 AX 0 0 16
[ 2] .data PROGBITS 23e0
WA 0 0 16
[ 3] .bss NOBITS 23e0
0008 WA 0 0 16
[ 4] .data.rel PROGBITS 23e0
06c0 WA 0 0 16
[ 5] .debug_frame PROGBITS 2aa0
0 0 8
[ 6] .symtab SYMTAB 2aa0
0d68 0018 711 4
[ 7] .strtab STRTAB 3808
1262 0 0 1
[ 8] .shstrtab STRTAB 4a6a
006d 0 0 1
[ 9] .note.GNU-stack PROGBITS 4ad7
0 0 1
[10] .rela.textRELA 4ad8
1308 0018 6 1 4
[11] .rela.data.relRELA 5de0
0870 0018 6 4 4
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Wed, 2011-01-12 at 12:05 +, Martin wrote: On 12/01/2011 11:53, Joost van der Sluis wrote: Well, the version I use has version 7.2.50.20110107-cvs. But those version-numbers are a mess. Especially since Fedora in fact uses a fork of gdb (Archer) but it has the same name. It's this fork I base my work on. And I don't think you can detect the difference between the forked (archer) gdb and the original one. Maybe another way to detect this is: (After an application is loaded, but you have to do this only once) set case off b MaiN - fails = old/no case-insensitive support = set case on (or auto) - works = new/working case-insensitive support = set case off Or is that too ugly? Maybe possible, but I would have to do it the save way, that is, the IDe needs to detect if gdb crashed, and then be able to restart, and omit... = that is some extra worrk... Or maybe, it will be enough if I just combine that with the version check too. (need to find out. No, I think it won't crash. (Mine old gdb didn't) Also need to see what else can be used in the version string: C:\FPC\GDB\7.2-50_joostgdb GNU gdb (GDB) 7.2.50.20101116-cvs Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. This GDB was configured as i686-pc-mingw32. Not sure what that was on fedora? Well, the official rpm: x86_64-redhat-linux-gnu, but he one I build myself: x86_64-unknown-linux-gnu Not sure if yur patched version can add something unique? That's possible. But give it some time and there will be other versions with these patches too. But to show what is possible, this is the outpu of an official rpm: GNU gdb (GDB) Fedora (6.8.50.20090302-40.fc11) Copyright (C) 2009 Free Software Foundation, Inc. So the 'Fedora' string is added. I could make it something like 'Pascal-edition' ? Alternatively, as soon as I fix the user-config for the debugger (in the ide options) to be persistent (there is a mantis issue, so apparently it doesn't work) Then I could just add an option, and leave it to the user... That's an idea. This is only useful if the user also uses -gw3. What are the chances for that to be fixed in In what...? Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offset and size of .note.GNU-stack section in object files
On 12 Jan 2011, at 13:12, Joost van der Sluis wrote: I saw that the offset of the section behind the .note.GNU-stack section has it's offset increased by one in comparison to the offset of the .note.GNU-stack section. But the length of this section is 0, so there shouldn't be an increase in the offset? Am I right, or do I miss something? Alignment: .rela.text alignment = 4, and align(0x4ad7,4) = 0x4ad8. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On 12/01/2011 12:20, Joost van der Sluis wrote: What are the chances for that to be fixed in In what...? Strange. Some of my mail didn't make it... What are the chances of the assertation bug being fixed in other branches of gdb? how soon? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offset and size of .note.GNU-stack section in object files
On Wed, 2011-01-12 at 13:22 +0100, Jonas Maebe wrote: On 12 Jan 2011, at 13:12, Joost van der Sluis wrote: I saw that the offset of the section behind the .note.GNU-stack section has it's offset increased by one in comparison to the offset of the .note.GNU-stack section. But the length of this section is 0, so there shouldn't be an increase in the offset? Am I right, or do I miss something? Alignment: .rela.text alignment = 4, and align(0x4ad7,4) = 0x4ad8. Offcourse, thanks. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
Am 12.01.11 11:39, schrieb Joost van der Sluis: That is bad news, because it seems like it that the final-case-sensitivity solution will be that the case-sensitive flag is used to control the behavior. But that will then break backwards compatibility... I have osx, freebsd, linux and windows as targets. Currently debugging with lazarus under osx is a horrible experience :-). (http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Known_Problems and more) Is there a chance to build (your) patched gdb versions for that targets too? So that there is the possibility to have the same (working) gdb version for all targets.(dreaming) Maybe even a static build? (more dreaming) As this is our daily business I think I am able to donate some time in testing/debugging/codeing too, if that could help. helmut ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Wed, 2011-01-12 at 12:23 +, Martin wrote:
On 12/01/2011 12:20, Joost van der Sluis wrote:
What are the chances for that to be fixed in
In what...?
Strange. Some of my mail didn't make it...
What are the chances of the assertation bug being fixed in other
branches of gdb? how soon?
Won't be soon. Because the patch to fix the case-insensitive searching
depends on another patch. (the full symtab expansion-patch) That patch
is quite big and leads to some regressions in the gdb-testsuite. Which
needs some more patches. All those patches are in the review-queue of
gdb, and this queue is huge...
So, half a year? A year?
More info: ('FSF gdb' is the original gdb-version)
http://sourceware.org/ml/gdb/2011-01/msg00029.html
Joost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
mac osx gdb [Re: [fpc-devel] Dwarf3 and the encoding of classes ]
On 12/01/2011 12:30, Helmut Hartl wrote: Am 12.01.11 11:39, schrieb Joost van der Sluis: That is bad news, because it seems like it that the final-case-sensitivity solution will be that the case-sensitive flag is used to control the behavior. But that will then break backwards compatibility... I have osx, freebsd, linux and windows as targets. Currently debugging with lazarus under osx is a horrible experience :-). (http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Known_Problems and more) You can search macports gdb for a gdb 7.1 for osx. BUT afaik it doesn't start app-bundles, you need to start the exe inside the bundle directly = which may cause other issues... Also the same may be true for the gdb discussed in these mails = afaik only the special gdb by apple does the bundle support = and that still is 6.3-50 --- Also the gdb of these mails, is about improved displaying of certain data types. - objects, if gdb is used outside the IDE = in the IDE it's already done - strings with index: SomeStringFoo[1] is the first (1-based index) char, but gdb thinks it is the 2nd. - some other data types... For your issues probably start a new mail thread (and on the lazarus list) = it it is about the way watches display data, then describe what you get, and what you expect.. = though in this case not all will be fixed in the IDE, and some may be better with this new gdb. = if it is, about the gdb hangs, or crashes then there will be a need for plenty of logs, etc. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpprofiler] bug
Resolved in revision 2521. I added your example to the test suite. Darius On Jan 12, 2011, at 7:13 AM, Alex Shishkin wrote: http://bugs.freepascal.org/view.php?id=18471 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
Martin Schreiber wrote / napísal(a): On Wednesday, 12. January 2011 09.45:47 LacaK wrote: So where is error ? 1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string -or- 2. Is it wrong in implementation of TSQLConnectors, which write data into record buffer (of TStringField) and do not convert them always into UTF-8 ? (if data should be always in UTF-8 then it will be good redefine TField.Text property like property Text: UTF8String to be clear, that we always work with UTF-8 strings) -or 3. I missed something ? ;-) MSEgui sqldb version converts to UTF-16 from/to system encoding or utf-8 (selectable by option properties) and uses FPC 16bit UnicodeString to store string field values in the dataset, the tmsestringfield returns UnicodeString values. So one can either use utf-8 encoded databaseconnections or connections with the current system encoding. MSEgui uses 16 bit UnicodeString everywhere, the conversion from/to system encoding is done transparently by the FPC unicode/widestring-manager if necessary. This is a solution which works now, no additional complicated and possibly less performant codepage and encoding aware stringtype necessary... Yes, sounds logicaly to me. Then you propose same way for TStringField ? (internaly store as UnicodeString UTF-16 and also TStringField.Text should return UnicodeString instead of String ? ... what will happens in LCL, when visual component will read UTF-16 string, will they be translated into UTF-8 automagicaly?) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On Wed, 2011-01-12 at 09:45 +0100, LacaK wrote: Sven Barth wrote / napísal(a): Am 12.01.2011 07:16, schrieb LacaK: P.S. I still does not understand, how can things work correctly if LCL expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does not strictly follow this (at least in Windows) ? LCL uses SysToUTF8 and UTF8ToSys if it uses the RTL (and the FCL). This is often done with wrappers that wrap the RTL method and do the conversion (e.g. FileExistsUTF8, etc.). As I wrote in any of my previous message, AFAIK this is not true in case of fcl-db and Lazarus data-aware components like TDBGrid, TDBEdit ... They use TField.Text: String property to get string conent of field and display them. AFAIU LCL expects, that TField.Text will always return UTF-8 encoded string (because no conversion (SysToUTF8) is done in dbgrids.pas or dbedit.inc) , but this is not true always. So where is error ? 1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string -or- 2. Is it wrong in implementation of TSQLConnectors, which write data into record buffer (of TStringField) and do not convert them always into UTF-8 ? (if data should be always in UTF-8 then it will be good redefine TField.Text property like property Text: UTF8String to be clear, that we always work with UTF-8 strings) -or 3. I missed something ? ;-) Didn't I explain this to you and others a few times? The database-components itself are encoding-agnostic. This means: encoding in = encoding out. So it is up to the developer what codepage he want to use. So TField.Text can have the encoding _you_ want. So, if you want to work with Lazarus, which uses UTF-8, you have to use UTF-8 encoded strings in your database. If there is some strange reason why you don't want the strings in your database to be UTF-8 encoded, you have to convert the strings from the encoding your database uses to UTF-8 while reading data from the database. Luckily, you can specify the encoding of strings you want to use for most databases. Not only the encoding in which the strings are stored, but also the encoding which has to be used when you send and retrieve data from the database. And you can set this for each connection made. Ie: you can resolve the problem by changing the connection-string, or by adding some connection-parameter. There's also another solution you can find on the forum and other places. You can convert the strings to UTF-8 not only when they are read from the database, but also when they are read from the internal memory. There's a hook for that. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On Wed, 2011-01-12 at 11:02 +0100, LacaK wrote: Yes, this is not primary question of database side, but db client library api, which is used by SQLConnector to retrieve data. For example in ODBC we use SQLGetData in LoadField method to retrieve data from odbc interface. And for example in case of MS SQL Server character data are retrieved in current ANSI code page (in Windows of course, may be that for example in *nix data are retrieved in UTF-8 naturaly) . (AFAIK there is no universal way how to explicitly request character encoding from ODBC interface) Almost each DB-server has a setting to specify the encoding, which has to be added to the connection-string. So it is true, that every sql connector is mandatory write character data in UTF-8 ? or can write in some native format (Ansi, UTF-16) ... but in this case must somewhere write additional info about actual encoding. If you add a hook that converts this data, yes. (I woudn't do that, use the database-servers functionality instead) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On Wednesday, 12. January 2011 14.27:14 LacaK wrote: Yes, sounds logicaly to me. Then you propose same way for TStringField ? (internaly store as UnicodeString UTF-16 and also TStringField.Text should return UnicodeString instead of String ? It is done so in MSEgui fork of sqldb. In case you don't know MSEide+MSEgui, it is here: http://developer.berlios.de/projects/mseide-msegui/ ... what will happens in LCL, when visual component will read UTF-16 string, will they be translated into UTF-8 automagicaly?) It works for MSEgui where all strings are utf-16 FPC UnicodeString. It does not work for Lazarus with the utf-8 encoded ansistrings. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
L but db client library api, which is used by SQLConnector to L retrieve data. How an UTF8 SQLConnector can retrieve UTF8 data from a field defined as binary ? It cann't . Here I am speaking about TStringField, which is IMHO designed for character data, for binary data is designed TBinaryField L For example in ODBC we use SQLGetData in LoadField L method to retrieve data from odbc interface. And for example in L case of MS SQL Server character data are retrieved in current ANSI L code page (in Windows of course, may be that for example in *nix L data are retrieved in UTF-8 naturaly) . Via ODBC ? L (AFAIK there is no universal way how to explicitly request L character encoding from ODBC interface) But that's a problem of ODBC, but: http://web.datadirect.com/resources/odbc/unicode/unix.html Yes in UNIX world it may be so (I do not know), but in Windows ODBC we have no such possibility AFAIK L So it is true, that every sql connector is mandatory write character L data in UTF-8 ? No. It is mandatory that you send/receive UTF8 to/from GUI LCL elements. As LCL elements are using TStringField.Text property, then this property should return UTF8String, right (not AnsiString in ANSI code page) ? If yes, then also TStringField must store internaly data in any unicode format (to not lose any characters), right ? So it can be UTF-8, UTF-16 or UTF-32 ... in all cases we must allocate space 4*[max.number of characters in field], right ? So in what encoding are string data stored now in TStringField ? -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On Wed, 2011-01-12 at 14:59 +0100, LacaK wrote: No. It is mandatory that you send/receive UTF8 to/from GUI LCL elements. As LCL elements are using TStringField.Text property, then this property should return UTF8String, right (not AnsiString in ANSI code page) ? If yes, then also TStringField must store internaly data in any unicode format (to not lose any characters), right ? So it can be UTF-8, UTF-16 or UTF-32 ... in all cases we must allocate space 4*[max.number of characters in field], right ? So in what encoding are string data stored now in TStringField ? The encoding you've specified. In the connection-string or some other database-server dependent setting. Not that when you want to use UTF-16 (or 32) you have to use TWideStringFields. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
kingbiz...@gmail.com wrote: I come here humbly to ask for a new implementation, the IIF ?:, the IIF is a shortcut that make the coding a little faster, it works by returning a true or a false part of a condition, a more detailed information can be found there: http://en.wikipedia.org/wiki/%3F: *PHP and C++ implementation:* Value *=* condition *?* value if true *:* value if false; *Pascal implementation:* Value := IfThen(Condition, TruePart, FalsePart); *function IfThen(Condition: Boolean; IfTrue, IfFalse: X): X; overload; begin if Condition then Result := IfTrue else Result := IfFalse; end; * Note that there is a tiny little difference between those two. the ?: operator evaluates either the TruePart or FalsePart while IfThen will evaluate both parts first. The following will succeed var p: PInteger; i: Integer; begin p := nil; i := p nil ? p^ : 0; end; The following will fail var p: PInteger; i: Integer; begin p := nil; i := IfThen(p nil, p^ , 0); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] String and UnicodeString and UTF8Stringt
Hello FPC, Wednesday, January 12, 2011, 2:59:53 PM, you wrote: L but db client library api, which is used by SQLConnector to L retrieve data. How an UTF8 SQLConnector can retrieve UTF8 data from a field defined as binary ? L It cann't . L Here I am speaking about TStringField, which is IMHO designed for L character data, for binary data is designed TBinaryField And a binary field is an string without encoding, collate and other text explicit attributes. But that's a problem of ODBC, but: http://web.datadirect.com/resources/odbc/unicode/unix.html L Yes in UNIX world it may be so (I do not know), L but in Windows ODBC we have no such possibility AFAIK Quote from Microsoft: The ODBC 3.5 (or higher) Driver Manager supports both ANSI and Unicode versions of all functions that accept pointers to character strings or SQLPOINTER in their arguments. The Unicode functions are implemented as functions (with a suffix of W), not as macros. The ANSI functions (which can be called with or without a suffix of A) are identical to the current ODBC API functions. ODBC 3.5 was launched around 2000-2001. L So it can be UTF-8, UTF-16 or UTF-32 ... in all cases we must allocate L space 4*[max.number of characters in field], right ? L So in what encoding are string data stored now in TStringField ? In the same format the database bring them to it. Database returns a bunch of bytes and a description of that bytes. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On Wed, Jan 12, 2011 at 21:24, Michael Schnell mschn...@lumino.de wrote: += does work for variables, even Strings. AFAIR, there already has been a discussion about += and friends for properties. In fact I don't see why the compiler not just generates x.a := x.a + y from x.a += y before doing any code generating, disregarding what x.a is. Of course an error message will occur if x.a is not writable for any reason. Blindly replacing a += b with a := a + b may lead to a semantic change if a is an expression with side-effects. Nevertheless, I do think that implementing += for properties is a good idea, but unfortunately FPC developers disagree. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On 01/12/2011 04:48 PM, Alexander Klenin wrote: Blindly replacing a += b with a := a + b may lead to a semantic change if a is an expression with side-effects. Nevertheless, I do think that implementing += for properties is a good idea, but unfortunately FPC developers disagree. I do see that also properties could show site effects when used in a += expression, as they are accessed twice. But is this (in nearly all cases) not exactly what the user would expect ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On Wed, 12 Jan 2011, Michael Schnell wrote: On 01/12/2011 04:48 PM, Alexander Klenin wrote: Blindly replacing a += b with a := a + b may lead to a semantic change if a is an expression with side-effects. Nevertheless, I do think that implementing += for properties is a good idea, but unfortunately FPC developers disagree. I do see that also properties could show site effects when used in a += expression, as they are accessed twice. But is this (in nearly all cases) not exactly what the user would expect ? Most of the time, yes. But there are some subtleties with interfaces and reference counting, which could bite you in the leg. (as they already have for some people). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
On 01/12/2011 05:01 PM, michael.vancann...@wisa.be wrote: reference counting, which could bite you in the leg. (as they already have for some people). I see. _Hidden_ side effects :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
On Thu, Jan 13, 2011 at 00:51, Marc Weustink marc.weust...@cuperus.nl wrote: Note that there is a tiny little difference between those two. the ?: operator evaluates either the TruePart or FalsePart while IfThen will evaluate both parts first. Exactly. This is why for me IfThen is much less useful then conditional operators in other languages. I think a better alternative would be Algol-like if-expression: a := (if x 0 then x else -x); -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
kingbiz...@gmail.com schrieb: I come here humbly to ask for a new implementation, the IIF ?:, the IIF is a shortcut that make the coding a little faster, it works by returning a true or a false part of a condition, a more detailed information can be found there: http://en.wikipedia.org/wiki/%3F: *PHP and C++ implementation:* Value *=* condition *?* value if true *:* value if false; *Pascal implementation:* Value := IfThen(Condition, TruePart, FalsePart); The standard Pascal implementation of the C ternary expression is a const Name: array[boolean] of type = (FalseFart, TruePart); and Value := Name[Condition]; DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
LacaK schrieb: ...: the new ansistring type has a hidden element size field (in addition to the reference count, length and codepage), and from what I can see at page 10 of http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf, Delphi 2009's unicodestring is simply an ansistring(1200). So it seems, that if we will have any GenericString, with properties reference count, size, character width, codepage, then all other string types can be based on this string type. So other strings will be only any shortcuts, and internaly will use same structure: AnsiString = GenericString(with actual system ANSI code page (0) ... or ... without any explicit codepage ($)) UTF8String = GenericString(with UTF-8 encoding) UnicodeString = GenericString(with UTF-16 encoding) Nice from management view, but resulting in an ugly implementation. Apart from the generic form of (internal) subroutines we still need explicit code for most variations. Also translation tables for *all* codpages must become part of every executable. A true polymorphic string class (or equivalent) would be more performant, and would allow to add only really used codepages to the applications. Such an implementation could add another VMT pointer to the string prefix, and the UnicodeString could be implemented by a simple type cast from any (generic) string reference into a class reference. Where is not agreement, it is fact what should be default string encoding (AnsiString($) or UTF-8 or UTF-16 or UTF-32) The default (internal) string type must be an UTF type, else losses are inevitable during (implicit) conversions. This means that SBCS AnsiString never can become the default encoding. The default type could be made platform dependent, so that UTF-16 would be used for Windows and UTF-8 for Linux platforms. But this will cause problems with code that assumes exactly one of these encodings, and uses indexed access to characters, when such code is recompiled for a platform with a different default encoding. The introduction of another type OSString or TFileName can eliminate many implicit conversions in passing such strings to subroutines, but OTOH can cause slowdown of all other operations with that string type. I'd ban indexed access at all, in the future, unless the default encoding is UTF-32; else the user has to accept an possible more or less significant slowdown of his code, what stands in contrast to the *intented* optimization by direct (indexed) access to the string content. Delphi has eliminated that discussion by declaring the (default) UnicodeString fixed to UTF-16, for all targets. The only remaining question is, whether this was the best choice at all. P.S. I still does not understand, how can things work correctly if LCL expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does not strictly follow this (at least in Windows) ? Right, UTF8String should be really different from AnsiString, so that all eventually required conversions can be inserted by the compiler. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
Jeff Wormsley schrieb: On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote: UTF-8 combines an single (byte-based) storage type with lossless encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look* easier to handle in user code, but both will fail and require special code whenever characters outside the assumed codepage may occur. Preface: I don't write international apps, and probably won't for the foreseeable future... Then you may be bound to some legacy compiler version when the stringhandling will change in some future time, as happened to Delphi users. Continued support of AnsiString type(s) is not enough, because legacy code can be broken by (eventually) required changes to set of char, sizeof(char) and PChar, sizeof(string) as opposed to Length(string), upper/lower conversion, and many more not so obvious consequences. Isn't all of this concentration on trying to make strings have single byte characters (who cares how they are encoded), using the argument that it is somehow faster, incorrect for just about any modern processor, including embedded CPU's such as ARM? It was my understanding that 32 bit aligned access was always faster than byte aligned access on just about any CPU FPC still supports. See Marco's comment about data size etc. The argument holds just fine for memory, but I don't really get the speed argument. Maybe I'm missing something. FPC (the compiler) still uses ShortStrings wherever possible, because that was found out as the most efficient string representation. This is partially due to the ASCII encoding of source code, except for string literals. But like you, I'm not sure that this argument still holds on modern hardware. Speed loss may occur due to: - data shuffling in general (total byte count) - (implied) string conversion - indexed access to MBCS[1] strings (including UTF-8/16) [1] All encodings of variable character size discourage indexed access to strings. Then char can have multiple meanings, as either representing the (physical) string/array *element* size, or the (logical) size of an *codepoint*. Until now most users, including you, most probably don't realize that difference between phyiscal and logical characters, and assume that sizeof(char) always is 1, and eventually that sizeof(WideChar) is 2. IMO variables of type char should have at least 3 (better 4) bytes in an Unicode environment, in order to maintain the correspondence between physical and logical characters. As already suggested the packed keyword could be applied to strings and char arrays, to definitely signal to the user that indexed access should not be used with such variables, unless a speed penalty is acceptable. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Den 12-01-2011 12:42, Jonas Maebe skrev: On 12 Jan 2011, at 06:29, Jeppe Johansen wrote: While trying to find a nice solution for generating interrupt vector tables on ARM, I found that the usually employed solution is to generate weak references to symbols, that are initialized to a single handler. This way an application can override the weak reference, by declaring a new symbol with the same name. While it's possible to do that currently by using some external assembler code, I think a simpler solution could be made by using the weakexternal directive. The infrastructure is already there, but it's used in a slightly different way. How is it normally done in C? At first sight, using the weakexternal directive to /define/ symbols seems like a wrong approach. Jonas With C it's done using compiler dependent attributes. With gcc you can do it using __attribute__((weak,alias(SomeFunction)));. Though often it'll just be done using assembler using the .weak and .set/thumb_set directives The weakexternal directive already defines a symbol, it will exist at runtime, but it might be nil. The only difference is that if you set the initial value it'll resolve to something at link time ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
On 12.01.2011 13:38, Hans-Peter Diettrich wrote: Jeff Wormsley schrieb: On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote: UTF-8 combines an single (byte-based) storage type with lossless encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look* easier to handle in user code, but both will fail and require special code whenever characters outside the assumed codepage may occur. Preface: I don't write international apps, and probably won't for the foreseeable future... Then you may be bound to some legacy compiler version when the stringhandling will change in some future time, as happened to Delphi users. Continued support of AnsiString type(s) is not enough, because legacy code can be broken by (eventually) required changes to set of char, sizeof(char) and PChar, sizeof(string) as opposed to Length(string), upper/lower conversion, and many more not so obvious consequences. I don't believe that PChar will be touched, because to much code that interfaces with C code depends on that. Although its declaration might not be the same then and become PChar = PAnsiChar instead of PChar = ^Char if Char is changed (currently its PAnsiChar = PChar). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
In our previous episode, michael.vancann...@wisa.be said: exactly what the user would expect ? Most of the time, yes. But there are some subtleties with interfaces and reference counting, which could bite you in the leg. (as they already have for some people). Moreover, that IMHO the c operators are mostly meant for porting of existing C code. And I never saw C code with properties :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
On 12 Jan 2011, at 19:16, Jeppe Johansen wrote:
Den 12-01-2011 12:42, Jonas Maebe skrev:
How is it normally done in C? At first sight, using the weakexternal
directive to /define/ symbols seems like a wrong approach.
With C it's done using compiler dependent attributes. With gcc you can do it
using __attribute__((weak,alias(SomeFunction)));. Though often it'll just
be done using assembler using the .weak and .set/thumb_set directives
FPC also has an alias procedural directive, so that one should probably be
used instead. Giving weakexternal (or anything else) a syntax that is not used
for any other procedure directive is not a good idea because it reduces
uniformity.
The weakexternal directive already defines a symbol, it will exist at
runtime, but it might be nil.
What I meant is that there is a semantic difference between referencing a
symbol that may or may not be defined somewhere else (regardless of whether a
programmer or the linker creates the referenced symbol), and defining a new
symbol. This is independent of whether a symbol is weak or not.
Defining a weak symbol also exists, but is not yet supported by FPC. In fact,
the example you gave would seem more logical to me as follows (assuming that
FPC could define weak symbols using the weak modifier):
procedure IRQHandler; weak;
begin
{ default dummy implementation, the NoHandler from your example }
end;
procedure MyIRQHandler; public; alias: 'IRQHandler';
begin
{ real implementation, overrides the weak definition of IRQHandler; if
there
is no such definition, the dummy one is used }
end;
(and of course, if we'd have a plain weak modifier, then weakexternal;
could be weak; external;, although this is annoying to still change because
weakexternal support is already in released FPC versions)
If you have no control over the original definition and it is not weak (maybe
the reason you did that is because FPC does not yet support defining weak
symbols), then we indeed need some way to define weak symbols whose default
value is something else than nil, because I guess wrapping is not good enough
(although it's not that bad, since it only results in an extra call in the case
where the weak symbol is not replaced):
procedure NoHandler;
begin
{ dummy implementation }
end;
procedure MyIRQHandler; weak;
begin
{ default behaviour: one extra call }
NoHandler;
end;
{ overriding implementation }
procedure RealIRQHandler; public; alias: 'MyIRQHandler';
begin
{ real code }
end;
I can't immediately think of a good syntax to directly define MyIRQHandler as a
weak symbol with the address of NoHandler as default value. Maybe this,
although I'm not 100% happy with it either:
procedure MyIRQHandler; weak 'NoHandler';
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variables declaraction inside code
In our previous episode, LacaK said: 3. C style comments: /* ... */ (I have never understood why in Pascal was used (* ... *) ) You probably have to formulate that the other way around. Pascal is older. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
In our previous episode, Hans-Peter Diettrich said: memory management and the occasional code page conversion (and since this may reduce the number of code page conversions when working with non-native strings, it can also be a performance win). IMO a single encoding, i.e. UTF-8, can cover all cases. Well, for starters, it doesn't cover the existing Delphi/unicode codebase. While some hard core Ansi coders may whine about such a convention, the absence of implicit string conversions (except in external library calls) will make such applications more performant than mixed-encoding versions. I don't see why this is the case. A current system encoding application does not do any conversion. (except for GUI output, and that can be considered negiable to the actual GUI overhead) Why spend time in the design of multiple RTL/LCL versions, when a single version will be perfectly sufficient? Why spent 13 years being compatible when you can throw it away in a second? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] help please - crash in realoc mem due to entercritical section
I recently startet getting the below error = 2.4.2 and trunk, so
probably not fpc.
But The particular code in Lazarus hasn't changed (from what it was
before I start getting the error)
If I step into it, then fpc_ansistr_concat get's 2 perfectly valid
strings (as far as I can see). Tha code is even in a loop , it works 3
or 4 times, then boom.
The issue is, I am at loss, where to even start looking. So any hints
will be welcome...
It happens if I run the gdb test case in lazarus= my version is
currently modified from the one in svn, but the debugger code, that
crashes is not modified.
#0 ntdll!RtlAddAccessDeniedObjectAce at :0
#1 ntdll!RtlAddAccessDeniedObjectAce at :0
#2 SYSENTERCRITICALSECTION(0) at ..\win\systhrd.inc:358
#3 ENTERCRITICALSECTION({DEBUGINFO = 0x0, LOCKCOUNT = 4, RECURSIONCOUNT
= 0, OWNINGTHREAD = 4294967292, LOCKSEMAPHORE = 10226112, SPINCOUNT =
10226116}) at ..\inc\thread.inc:202
#4 WAITFREE_VAR(0xfffc) at ..\inc\heap.inc:1081
#5 SYSFREEMEM_VAR(0x0, 0x0) at ..\inc\heap.inc:1144
#6 SYSFREEMEM(0xfffc) at ..\inc\heap.inc:1186
#7 SYSREALLOCMEM(0x9c09c4, 4294967292) at ..\inc\heap.inc:1432
#8 REALLOCMEM(0x0, 4) at ..\inc\heap.inc:317
#9 fpc_ansistr_setlength(0x2c4210 #1, 10226116) at ..\inc\astrings.inc:580
#10 fpc_ansistr_concat(0x2c4210 #1, 0x2c4218 'type = TOBJECT = class
'#13#10' public'#13#10'constructor CREATE (TOBJECT, POINTER) :
^TOBJECT;'#13#10'destructor ~DESTROY (TOBJECT, POINTER);
virtual;'#13#10'function NEWINSTANCE (unnamedtype) : ^TOBJECT;
vir'..., 0x2f0640 'function SAFECALLEXCEPTION (TOBJECT, TOBJECT,
POINTER) : LONGINT; virtual;'#13#10) at ..\inc\astrings.inc:225
#11 DOCONSOLESTREAM(0x4a0e598, 0x2f0640 'function SAFECALLEXCEPTION
(TOBJECT, TOBJECT, POINTER) : LONGINT; virtual;'#13#10) at
..\debugger\gdbmidebugger.pp:8157
#12 PROCESSRESULT(0x2f0698, {STATE = DSNONE, VALUES = 0x2c4210 #1, FLAGS
= []}, -1) at ..\debugger\gdbmidebugger.pp:8223
#13 EXECUTECOMMAND(0x2f0698, 0x98ed00 'ptype TObject', {STATE = DSNONE,
VALUES = 0x2c4210 #1, FLAGS = []}, [], -1) at
..\debugger\gdbmidebugger.pp:8036
#14 DOEXECUTE(0x2f0698) at ..\debugger\gdbmidebugger.pp:2980
#15 EXECUTE(0x2f0698) at ..\debugger\gdbmidebugger.pp:8776
#16 RUNQUEUE(0x6442008) at ..\debugger\gdbmidebugger.pp:4781
#17 QUEUECOMMAND(0x6442008, 0x2f0698, false) at
..\debugger\gdbmidebugger.pp:4878
#18 STARTDEBUGGING(0x6442008, 0x2d42f0) at ..\debugger\gdbmidebugger.pp:5770
#19 STARTDEBUGGING(0x6442008, ECTCONTINUE) at
..\debugger\gdbmidebugger.pp:5754
#20 GDBRUN(0x6442008) at ..\debugger\gdbmidebugger.pp:5094
#21 REQUESTCOMMAND(0x6442008, DCRUN, {}, -1) at
..\debugger\gdbmidebugger.pp:5554
#22 REQCMD(0x6442008, DCRUN, {}, -1) at ..\debugger\debugger.pp:2130
#23 RUN(0x6442008) at ..\debugger\debugger.pp:2144
#24 TESTWATCHES(0x32a4d8) at testwatches.pas:607
#25 RUNTEST(0xfffc) at src\fpcunit.pp:867
#26 RUNBARE(0x32a4d8) at src\fpcunit.pp:845
#27 PROTECTTEST(0x0, 0x4) at src\fpcunit.pp:1177
#28 RUNPROTECTED(0x5f824b0, 0x32a4d8, {procedure (TTEST, TTESTRESULT)}
0x4a0f26c) at src\fpcunit.pp:1201
#29 RUN(0xfffc, 0x9c09c0) at src\fpcunit.pp:1186
#30 RUN(0x4, 0x0) at src\fpcunit.pp:835
#31 RUNTEST(0x0, 0xfffc, 0x4) at src\fpcunit.pp:1035
#32 RUN(0x0, 0x0) at src\fpcunit.pp:1026
#33 GUITESTRUNNER_TGUITESTRUNNER_$__RUNTEST$TTEST at :0
#34 GUITESTRUNNER_TGUITESTRUNNER_$__ACTRUNHIGHLIGHTEDTESTEXECUTE$TOBJECT
at :0
#35 EXECUTE(0x0) at ..\objpas\classes\action.inc:124
#36 EXECUTE(0x2f4770) at include\containedaction.inc:104
#37 EXECUTE(0x2f4770) at include\customaction.inc:252
#38 EXECUTE(0x5fad638, 0x5f57e00) at ..\objpas\classes\action.inc:49
#39 CLICK(0x5f57e00) at include\control.inc:2285
#40 CLICK(0x5f57e00) at include\buttoncontrol.inc:62
#41 CLICK(0x5f57e00) at include\buttons.inc:174
#42 CLICK(0x5f57e00) at include\bitbtn.inc:57
#43 WMDEFAULTCLICKED(0x5f57e00, {MSG = 66567, WPARAM = 0, LPARAM = 0,
RESULT = 0, WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 0, LPARAMHI = 0,
RESULTLO = 0, RESULTHI = 0}) at include\buttoncontrol.inc:26
#44 DISPATCH(0x0, 0) at ..\inc\objpas.inc:592
#45 WNDPROC(0x5f57e00, {MSG = 66567, WPARAM = 0, LPARAM = 0, RESULT = 0,
WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 0, LPARAMHI = 0, RESULTLO = 0,
RESULTHI = 0}) at include\control.inc:1684
#46 WNDPROC(0x5f57e00, {MSG = 66567, WPARAM = 0, LPARAM = 0, RESULT = 0,
WPARAMLO = 0, WPARAMHI = 0, LPARAMLO = 0, LPARAMHI = 0, RESULTLO = 0,
RESULTHI = 0}) at include\wincontrol.inc:5241
#47 DELIVERMESSAGE(0x5f57e00, 0) at lclmessageglue.pas:110
#48 WINDOWPROC(7865768, 273, 32256, 656944) at win32callback.inc:2441
#49 USER32!GetWindowMinimizeRect at :0
#50 IDENTPROC(0x111) at synhighlighterhtml.pp:2122
#51 USER32!GetWindowMinimizeRect at :0
#52 GETNEEDPARENTPAINT(0x0, 0xcacd1342) at win32callback.inc:213
#53 USER32!CallNextHookEx at :0
#54 USER32!SendNotifyMessageA at :0
#55 DllInstall at :0
#56 DllInstall at :0
#57 DllInstall at :0
#58 USER32!GetWindowMinimizeRect at :0
#59 ?? at :0
#60
solved [Re: [fpc-devel] help please - crash in realoc mem due to entercritical section]
On 12/01/2011 21:15, Martin wrote: I recently startet getting the below error = 2.4.2 and trunk, so probably not fpc. Solved the talk about it effect. I had an out of range memory access in completely unrelated code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
In our previous episode, Sven Barth said: legacy code can be broken by (eventually) required changes to set of char, sizeof(char) and PChar, sizeof(string) as opposed to Length(string), upper/lower conversion, and many more not so obvious consequences. I don't believe that PChar will be touched, because to much code that interfaces with C code depends on that. Although its declaration might not be the same then and become PChar = PAnsiChar instead of PChar = ^Char if Char is changed (currently its PAnsiChar = PChar). Current Delphi _does_ regard char as equivalent lowlevel type to string. So whatever you choose as string (8 or 16-bit), pchar will match it by changing to pansichar or pwidechar ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Den 12-01-2011 20:47, Jonas Maebe skrev:
The weakexternal directive already defines a symbol, it will exist at
runtime, but it might be nil.
What I meant is that there is a semantic difference between referencing a
symbol that may or may not be defined somewhere else (regardless of whether a
programmer or the linker creates the referenced symbol), and defining a new
symbol. This is independent of whether a symbol is weak or not.
Defining a weak symbol also exists, but is not yet supported by FPC. In fact, the example you gave
would seem more logical to me as follows (assuming that FPC could define weak symbols
using the weak modifier):
procedure IRQHandler; weak;
begin
{ default dummy implementation, the NoHandler from your example }
end;
procedure MyIRQHandler; public; alias: 'IRQHandler';
begin
{ real implementation, overrides the weak definition of IRQHandler; if
there
is no such definition, the dummy one is used }
end;
(and of course, if we'd have a plain weak modifier, then weakexternal; could be weak;
external;, although this is annoying to still change because weakexternal support is already in
released FPC versions)
If you have no control over the original definition and it is not weak (maybe the reason
you did that is because FPC does not yet support defining weak symbols), then we indeed
need some way to define weak symbols whose default value is something else
than nil, because I guess wrapping is not good enough (although it's not that bad, since
it only results in an extra call in the case where the weak symbol is not replaced):
procedure NoHandler;
begin
{ dummy implementation }
end;
procedure MyIRQHandler; weak;
begin
{ default behaviour: one extra call }
NoHandler;
end;
{ overriding implementation }
procedure RealIRQHandler; public; alias: 'MyIRQHandler';
begin
{ real code }
end;
I can't immediately think of a good syntax to directly define MyIRQHandler as a
weak symbol with the address of NoHandler as default value. Maybe this,
although I'm not 100% happy with it either:
procedure MyIRQHandler; weak 'NoHandler';
Maybe something like instead? Requiring a symbol reference to a matching
implementation of a default value, like Paul suggested, would make the
solution more Pascal-like
procedure NoHandler;
begin
{ dummy implementation }
end;
{ Declaration NoHandler must exist and match }
procedure MyIRQHandler; weak NoHandler;
{ This will emit just a weak reference, the same as weakexternal; Not
guaranteed to be resolved after compiletime }
procedure MyIRQHandler2; weak;
This of course just introduces a new keyword weak, which was why I tried
to base it off the weakexternal keyword
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
On 12 Jan 2011, at 22:54, Jeppe Johansen wrote:
Den 12-01-2011 20:47, Jonas Maebe skrev:
I can't immediately think of a good syntax to directly define MyIRQHandler
as a weak symbol with the address of NoHandler as default value. Maybe this,
although I'm not 100% happy with it either:
procedure MyIRQHandler; weak 'NoHandler';
Maybe something like instead? Requiring a symbol reference to a matching
implementation of a default value, like Paul suggested, would make the
solution more Pascal-like
procedure NoHandler;
begin
{ dummy implementation }
end;
{ Declaration NoHandler must exist and match }
procedure MyIRQHandler; weak NoHandler;
The type checking will have to be delayed, since you can only compare the
procdef types after the entire second declaration has been parsed (there could
e.g. still be calling convention modifiers after that).
{ This will emit just a weak reference, the same as weakexternal; Not
guaranteed to be resolved after compiletime }
procedure MyIRQHandler2; weak;
This of course just introduces a new keyword weak, which was why I tried to
base it off the weakexternal keyword
This second example cannot be the same as weakexternal. Just like a regular
external declaration does not generate any data, code or reference by itself,
a weakexternal declaration does not do so either. external/weakexternal are
simply Pascal-level aliases that can be used to refer to non-Pascal external
symbols, a bit like absolute can be used for Pascal symbols.
I don't think that procedure MyIRQHandler2; weak; without any implementation
should be allowed. It would create a weak symbol in the middle of nowhere, not
associated with any particular code or data (and hence probably merged by the
linker with the next symbol in the section). It would be the same as allowing
procedure MyIRQHandler2; without any code or (weak)external.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Den 12-01-2011 23:18, Jonas Maebe skrev:
On 12 Jan 2011, at 22:54, Jeppe Johansen wrote:
Den 12-01-2011 20:47, Jonas Maebe skrev:
I can't immediately think of a good syntax to directly define MyIRQHandler as a
weak symbol with the address of NoHandler as default value. Maybe this,
although I'm not 100% happy with it either:
procedure MyIRQHandler; weak 'NoHandler';
Maybe something like instead? Requiring a symbol reference to a matching
implementation of a default value, like Paul suggested, would make the solution
more Pascal-like
procedure NoHandler;
begin
{ dummy implementation }
end;
{ Declaration NoHandler must exist and match }
procedure MyIRQHandler; weak NoHandler;
The type checking will have to be delayed, since you can only compare the
procdef types after the entire second declaration has been parsed (there could
e.g. still be calling convention modifiers after that).
Okay. Do you have any tip on where the best place to compare them would
be? The initial proposal did it in read_proc, but if the implementation
of the procedure comes after, this probably wouldn't be the right place
to do it
{ This will emit just a weak reference, the same as weakexternal; Not
guaranteed to be resolved after compiletime }
procedure MyIRQHandler2; weak;
This of course just introduces a new keyword weak, which was why I tried to
base it off the weakexternal keyword
This second example cannot be the same as weakexternal. Just like a regular external
declaration does not generate any data, code or reference by itself, a weakexternal declaration does not do
so either. external/weakexternal are simply Pascal-level aliases that can be used to refer to non-Pascal external
symbols, a bit like absolute can be used for Pascal symbols.
I don't think that procedure MyIRQHandler2; weak; without any implementation should be allowed.
It would create a weak symbol in the middle of nowhere, not associated with any particular code or data (and
hence probably merged by the linker with the next symbol in the section). It would be the same as allowing
procedure MyIRQHandler2; without any code or (weak)external.
The following is allowed currently, even if no Test symbol exists in the
linked objects. The declaration doesn't emit anything, except for a
.weak Test assembler directive if it's used. If Test is not used,
nothing will be emitted
procedure Test; weakexternal;
procedure SomeOtherFunction;
begin
Test;
end.
But I think you're right, that it would make a lot of sense not to allow it
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Dwar2 changed?
Has dwarf 2 changed ? with trunk ( I updated from a few month back, to today), I no longer get the classname of an exception (stabs is fine, but dwarf now fails) TCmdLineDebugger.SendCmdLn -data-evaluate-expression ^^shortstring(^POINTER($eax)^+12)^^ TCmdLineDebugger.ReadLn ^done,value=#0 repeats 20 times TCmdLineDebugger.ReadLn (gdb) GNU gdb (GDB) Fedora (7.1-18.fc13) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
On Wed, Jan 12, 2011 at 7:38 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Until now most users, including you, most probably don't realize that difference between phyiscal and logical characters, and assume that sizeof(char) always is 1 Oh, I'm aware of it. But to date, I haven't had to really deal with it in Delphi or FPC. My use of strings is either ancient legacy (from TP/BP days) where I simply changed all references to string to shortstring or low level Windows API code, where I'm dealing with PChar. I find these discussions fascinating, but as they say in the southern US, I don't have a dog in this hunt. Whatever the decision, I'll probably continue to use shortstring. Jeff. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] += with properties
Michael Schnell schrieb: += does work for variables, even Strings. AFAIR, there already has been a discussion about += and friends for properties. In fact I don't see why the compiler not just generates x.a := x.a + y from x.a += y before doing any code generating, This would result in the same error, because x.a is not an lval. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: memory management and the occasional code page conversion (and since this may reduce the number of code page conversions when working with non-native strings, it can also be a performance win). IMO a single encoding, i.e. UTF-8, can cover all cases. Well, for starters, it doesn't cover the existing Delphi/unicode codebase. Because it's bound to UTF-16? That's not a problem, because WideString will continue to exist, and according conversions are still inserted by the compiler. While some hard core Ansi coders may whine about such a convention, the absence of implicit string conversions (except in external library calls) will make such applications more performant than mixed-encoding versions. I don't see why this is the case. A current system encoding application does not do any conversion. (except for GUI output, and that can be considered negiable to the actual GUI overhead) When system encoding changes with the target platform, indexed access to such strings can lead to different results. Unless the compiler can read the coder's mind... Why spend time in the design of multiple RTL/LCL versions, when a single version will be perfectly sufficient? Why spent 13 years being compatible when you can throw it away in a second? It's sufficient to throw away what's no more needed :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwar2 changed?
On Wed, 2011-01-12 at 23:52 +, Martin wrote: Has dwarf 2 changed ? Yes with trunk ( I updated from a few month back, to today), I no longer get the classname of an exception (stabs is fine, but dwarf now fails) Well, passing variables to procedures by reference has different Dwarf-debug information now. And there are some changes which in theory shoudn't change anything, but maybe I made a mistake. You could try to compile an example with an older version and a newer version. And compare the output of 'objdump -W' TCmdLineDebugger.SendCmdLn -data-evaluate-expression ^^shortstring(^POINTER($eax)^+12)^^ TCmdLineDebugger.ReadLn ^done,value=#0 repeats 20 times TCmdLineDebugger.ReadLn (gdb) You do realize that this is an hack? (I partly wrote it) It could also be that the location of the exception-name has been changed by something. This hack doesn't use any debug-information. Only the definitions of a shortstring and pointer. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
