RE : [fpc-devel] Breaking change in FPC 2.6.1
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-boun...@lists.freepascal.org] De la part de Marco van de Voort Envoyé : mardi 24 avril 2012 23:13 À : FPC developers' list Objet : Re: [fpc-devel] Breaking change in FPC 2.6.1 In our previous episode, Martin Schreiber said: Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks FPC 2.6.0 compatible code. Is this intended? Yes. It should not break proper code (since that would already treat it as abstract type and call freebookmark). It broke also lazarus, MDO, rxmemds. TBookmark is defined as Pointer which has no automatic memory management so probably TDataset.FreeBookmark() must be called in a try finally block for every assignment of TDataset.Bookmark to a variable. As intended too? I first changed it to tbytes (as it is in D2009+), but got some comments that that was very incompatible, and a lot of method signatures would change. So I kept it pchar. (planning to change it to tbytes in trunk eventually) If it were pchar we wouldn't have the problems since pchar and string are assignment compatible. It is pointer now. Don't know where the comments came from but here we are in a situation where most 3rd party datasets had to be adapted to the change to pointer and will have to change again to tbytes later on. On top of that the freebookmark that a lot of third code had to add to catch up to the change to pointer isn't needed anymore for tbytes as it is a managed type. Why not bite the bullet immediately and just skip pointer? Avoiding incompatibility clearly failed. On the Delphi forums, similar discussions have been going on: people complaining about the different Tbookmark implementations and having to change their code. Wish we could have learned from that. Freebookmark should have been called already, afaik it is at least since D2006, if not easier, and FPC also implements it quite a while. http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookmark Quote: TBookmark is an alias of TBytes. This means that TBookmark is automatically garbage collected when it goes out of scope. Because TBookmark does not need to free memory, the FreeBookmark method is blank for the default implementation. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Ludo Brands said: It broke also lazarus, MDO, rxmemds. They mostly track 2.7.1 also, so then it should be just a matter of enabling the right override for 2.6.x too (which is what I had in mind) I first changed it to tbytes (as it is in D2009+), but got some comments that that was very incompatible, and a lot of method signatures would change. So I kept it pchar. (planning to change it to tbytes in trunk eventually) If it were pchar we wouldn't have the problems since pchar and string are assignment compatible. It is pointer now. Sorry, mixed up with the trecordbuffer stuff again, which I kept pchar, which is not later Delphi compatible, as Martin Schreiber clearly exposed in his mail. The bookmark situation is different. I can't really recall what the rationale was atm. I assume the main rationale was to simply start with creating a division between tbookmark and tbookmarkstr. Don't know where the comments came from but here we are in a situation where most 3rd party datasets had to be adapted to the change to pointer and will have to change again to tbytes later on. On top of that the freebookmark that a lot of third code had to add to catch up to the change to pointer isn't needed anymore for tbytes as it is a managed type. Why not bite the bullet immediately and just skip pointer? Avoiding incompatibility clearly failed. That can be discussed. Specially if sb can confirm that it works. I can however remember having read that freebookmark is still recommended, and if I look at the method, it is virtual and allows descendants to do extra processing. Probably because one can't trigger and event on freeing of an automated type (at least not the array based ones, interfaces is a differnet matter) But I assume that is more for the dataset users that use tbookmark than for internal use in tdataset implementers. On the Delphi forums, similar discussions have been going on: people complaining about the different Tbookmark implementations and having to change their code. Wish we could have learned from that. That's why I waited a while with merging, so that initially only 2.7.1 would be broken, and after a time without complaints, I merged it because then it is only the matter of connecting that change also with 2.6.1. Freebookmark should have been called already, afaik it is at least since D2006, if not easier, and FPC also implements it quite a while. http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookmark Quote: TBookmark is an alias of TBytes. This means that TBookmark is automatically garbage collected when it goes out of scope. Because TBookmark does not need to free memory, the FreeBookmark method is blank for the default implementation. True. But it is virtual, so if your code is agnostic wrt the dataset you use, or can be layered on top of otther datasets, you should call freebookmark probably even if it doesn't for the default dataset. IOW my idea is document and recommendthe way that always works now, not shortcuts that may be possible for historic reasons. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
It broke also lazarus, MDO, rxmemds. They mostly track 2.7.1 also, so then it should be just a matter of enabling the right override for 2.6.x too (which is what I had in mind) I understand. Just wanted to clarify that, to my knowledge, all 3rd party dataset descendants and some other programs using bookmarks are affected by a change that wanted to minimize compatibility problems. to the change to pointer isn't needed anymore for tbytes as it is a managed type. Why not bite the bullet immediately and just skip pointer? Avoiding incompatibility clearly failed. That can be discussed. Specially if sb can confirm that it works. I can however remember having read that freebookmark is still recommended, and if I look at the method, it is virtual and allows descendants to do extra processing. Probably because one can't trigger and event on freeing of an automated type (at least not the array based ones, interfaces is a differnet matter) But I assume that is more for the dataset users that use tbookmark than for internal use in tdataset implementers. That only would be useful if the tdataset descendant would add code around Tbookmark that would turn a managed type into a partially non-managed type. IMHO that would be only the case for those datasets that were developped with the intermediate non-managed Tbookmark=pointer. I can't imagine a tdataset implementer that would turn a managed bookmark type to an unmanaged one on purpose. Delphi has lived 2-3 years with the Tbookmark=pointer situation and probably has created there some backwards compatibility problems. One more reason to jump to tbytes as quickly as possible. On the Delphi forums, similar discussions have been going on: people complaining about the different Tbookmark implementations and having to change their code. Wish we could have learned from that. That's why I waited a while with merging, so that initially only 2.7.1 would be broken, and after a time without complaints, I merged it because then it is only the matter of connecting that change also with 2.6.1. I should have spoken up earlier then ;) The mention that the change to tbytes is in the pipeline for trunk was what triggered my reaction. Freebookmark should have been called already, afaik it is at least since D2006, if not easier, and FPC also implements it quite a while. http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookm ark Quote: TBookmark is an alias of TBytes. This means that TBookmark is automatically garbage collected when it goes out of scope. Because TBookmark does not need to free memory, the FreeBookmark method is blank for the default implementation. True. But it is virtual, so if your code is agnostic wrt the dataset you use, or can be layered on top of otther datasets, you should call freebookmark probably even if it doesn't for the default dataset. IOW my idea is document and recommendthe way that always works now, not shortcuts that may be possible for historic reasons. If we skip Tbookmark=pointer, at least fpc won't create new 'historic reasons' for requiring freebookmark. Delphi created a mess. Don't let us add to it. Having an empty freebookmark implementation will ease migration from Delphi code that needed it at one point in time. Just make that new fpc code won't need it. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
On 25 April 2012 11:08, Ludo Brands ludo.bra...@free.fr wrote: I understand. Just wanted to clarify that, to my knowledge, all 3rd party dataset descendants and some other programs using bookmarks are affected by a change that wanted to minimize compatibility problems. Indeed, and it now has the total opposite effect. Shouldn't such code breaking changes be left to Trunk (2.7.1) and new major FPC releases only. As far as I know, 2.6.x is now a fixes branch which should only allow _bug fix_ commits - nothing more! [Marco: practice what you preach] -- Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Graeme Geldenhuys wrote on Wed, 25 Apr 2012: On 25 April 2012 11:08, Ludo Brands ludo.bra...@free.fr wrote: I understand. Just wanted to clarify that, to my knowledge, all 3rd party dataset descendants and some other programs using bookmarks are affected by a change that wanted to minimize compatibility problems. Indeed, and it now has the total opposite effect. Shouldn't such code breaking changes be left to Trunk (2.7.1) and new major FPC releases only. As far as I know, 2.6.x is now a fixes branch which should only allow _bug fix_ commits - nothing more! That's not entirely correct. It's of course mainly for fixes, but small new features or important bug fixes that may break backwards compatibility can also be merged under certain circumstances. What is acceptable and what is not is obviously in the eye of the beholder, and it's not uncommon to also have internal discussions about that among the core developers. [Marco: practice what you preach] If your intention is to get this resolved to your satisfaction, then making it personal probably also has the total opposite effect. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
On 25 April 2012 13:10, Jonas Maebe jonas.ma...@elis.ugent.be wrote: That's not entirely correct. Ah yes, the core developers live by different rules to all of use. features or important bug fixes that may break backwards compatibility can also be merged under certain circumstances. Strange then that in the last few years of me using FPC released versions and tracking the fixes branch, I can't recall every seeing a merge that breaks so much code in a stable release - yet is allowed to stay. Hell, I asked for much less in the past - and that was declined purely because it was a minor new feature - even though it wouldn't break anybody's code. -- Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange Problem!
You program isn't valid. You're assigning a constant (a global
variable) to Result, so you shouldn't change it's contents through a
pointer (if you change it normally the compiler+RTL will COW the
value).
You can use a shortstring or:
Result := StringOfChar(' ', 16);
-Flávio
On Tue, Apr 24, 2012 at 7:36 PM, Amir a...@aavani.net wrote:
Hi,
I have encountered a strange problem. I developed the following function as
a faster implementation for IntToStr:
function MyIntToStr (n: Int64): AnsiString;
const
MaxLength= 16;
var
CurDigit: PChar;
Sign: Boolean;
begin
Result:= ' ';
CurDigit:= @(Result [MaxLength]);
Sign:= False;
if n 0 then
begin
Sign:= True;
n:= -n;
end;
if n= 0 then
Exit ('0');
while n 0 do
begin
CurDigit^:= Char (48+ n mod 10);
Dec (CurDigit);
n:= n div 10;
end;
if Sign then
CurDigit^:= '-';
end;
And then, in main , I have
begin
WriteLn (MyIntToStr (5458));
WriteLn (MyIntToStr (5458));
WriteLn (MyIntToStr (2));
end.
The output is:
5458
5458
5452
I tried gdb and noticed the first line of MyIntToStr (Result:= '...') is not
executed correctly. I am using fpc-2.6.0-1.x86_64
Thanks,
Amir
___
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: RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Ludo Brands said: They mostly track 2.7.1 also, so then it should be just a matter of enabling the right override for 2.6.x too (which is what I had in mind) I understand. Just wanted to clarify that, to my knowledge, all 3rd party dataset descendants and some other programs using bookmarks are affected by a change that wanted to minimize compatibility problems. Summary: afaik I wanted the change to go over as quickly as possible, but I assumed that a more freebookmark based approach was eventually the way to go anyway (and I still think that, unless the virtual is removed in XE2) I can only assume I chose pointer for minimal modifications AND to make people aware of it, so that unfreed bookmarks would show up in the heaptraces, so that at least the FPC+Lazarus codebase properly calls freebookmark everywhere. But I assume that is more for the dataset users that use tbookmark than for internal use in tdataset implementers. That only would be useful if the tdataset descendant would add code around Tbookmark that would turn a managed type into a partially non-managed type. Yes, for instance if there are external resources like cursors or locks coupled to it, and it is not just a matter of freeing that single block of memory. IMHO that would be only the case for those datasets that were developped with the intermediate non-managed Tbookmark=pointer. And I hope for all future datasets and code using it. Since the method is still virtual, and I could take even the old string version simply only as a label or handle to an external resource. (cursors, indexes, locks) The fact that it is an automated string then only buys the freeing of the label, but doesn't solve the problem. There is no ability to run code that way. I can't imagine a tdataset implementer that would turn a managed bookmark type to an unmanaged one on purpose. Delphi has lived 2-3 years with the Tbookmark=pointer situation and probably has created there some backwards compatibility problems. One more reason to jump to tbytes as quickly as possible. Afaik the assumption that it is /modeled/ as managed is simply wrong. It is currently modeled as NOT managed, it is just that for historic reasons managed works for the default base TDataset. But descendents don't have to support that (e.g. if they don't support old Delphi versions, something that is increasingly happening, with the first D7 supports disappearing) That's why I waited a while with merging, so that initially only 2.7.1 would be broken, and after a time without complaints, I merged it because then it is only the matter of connecting that change also with 2.6.1. I should have spoken up earlier then ;) The mention that the change to tbytes is in the pipeline for trunk was what triggered my reaction. Ideally, in time we want the interface to be the same as current Delphi's. But note that changing it to tbytes IMHO doesn't mean you can skip freebookmark, if you do that you cut corners, and program for a specific tdataset IOW my idea is document and recommendthe way that always works now, not shortcuts that may be possible for historic reasons. If we skip Tbookmark=pointer, at least fpc won't create new 'historic reasons' for requiring freebookmark. I think freebookmark is not historic. Code that treated tbookmark opague, and called freebookmark remained working with the change of tbytes. That is good design. It also gives a lot of freedom to dataasets to implement bookmark support. Opague type use is a good habit. Delphi created a mess. Don't let us add to it. (to be honest, I think that the tbytes stuff is the mess. Bowing to pressure, compromising design. But I bet the idea is still that you call freebookmark) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Graeme Geldenhuys said: Ah yes, the core developers live by different rules to all of use. Graeme, please stick to the topic, and leave your perceived project management whining out of it. If you want to avoid these kind of issues, I encourage you to step up your trunk testing to at least once every six weeks, and speak up in time next time. (and preferably on topic, with patches and testdata) Without serious testing of trunk, it is hard to take your criticism on policies seriously, since all you do is criticise in retrospect. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
Yes, for instance if there are external resources like cursors or locks coupled to it, and it is not just a matter of freeing that single block of memory. ... Afaik the assumption that it is /modeled/ as managed is simply wrong. It is currently modeled as NOT managed, it is just that for historic reasons managed works for the default base TDataset. But descendents don't have to support that (e.g. if they don't support old Delphi versions, something that is increasingly happening, with the first D7 supports disappearing) The underlying problem is that the Delphi Tbookmark definition migrated from the simple record tag to something that holds (or can hold) the state of the record. Ideally, in time we want the interface to be the same as current Delphi's. But note that changing it to tbytes IMHO doesn't mean you can skip freebookmark, if you do that you cut corners, and program for a specific tdataset OK. I understand your point. But now that the dataset implementers, who follow 2.7.1 as you indicated, have added freebookmark to their code, can we move on the next phase: tbytes? No need to linger on TBookmark=pointer. For most implementers the TBookmark changes are still fresh in memory and the sooner we get over with it the better. If creating the patch is the issue, I'm volunteering ;) Thanks, Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ARM embedded, how to deal with interrupts
Hello, can someone please provide an example, how interrupt handling for STM32F1x is done with fpc? I would like to see how an I/O signal may trigger an (interrupt) procedure. Thanks. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Ludo Brands said: that is increasingly happening, with the first D7 supports disappearing) The underlying problem is that the Delphi Tbookmark definition migrated from the simple record tag to something that holds (or can hold) the state of the record. A reason the more to not rely on implementation details, but treat it as an opague type as much as possible. But note that changing it to tbytes IMHO doesn't mean you can skip freebookmark, if you do that you cut corners, and program for a specific tdataset OK. I understand your point. But now that the dataset implementers, who follow 2.7.1 as you indicated, have added freebookmark to their code, can we move on the next phase: tbytes? No need to linger on TBookmark=pointer. Well, are you sure that the whole FPC+Lazarus codebases properly use freebookmark everywhere? Kidding, I never expected this much drama. If it is such big deal, and since we all agree over the eventual (tbytes) outcode let's just fix it. Make a patch, but do it in a way that keeps the current behaviour under (not active) ifdef if possible (nonautomatedbookmark or so). That way if we want to cleanup/detect missing freebookmarks, we only have to define that. That was probably the whole intended purpose of the exercise anyway. (and I do encourage people to test their code with that setting) If creating the patch is the issue, I'm volunteering ;) You can do it, if not, I will in the coming days. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
On Wed, 25 Apr 2012, Marco van de Voort wrote: In our previous episode, Ludo Brands said: that is increasingly happening, with the first D7 supports disappearing) The underlying problem is that the Delphi Tbookmark definition migrated from the simple record tag to something that holds (or can hold) the state of the record. A reason the more to not rely on implementation details, but treat it as an opague type as much as possible. But note that changing it to tbytes IMHO doesn't mean you can skip freebookmark, if you do that you cut corners, and program for a specific tdataset OK. I understand your point. But now that the dataset implementers, who follow 2.7.1 as you indicated, have added freebookmark to their code, can we move on the next phase: tbytes? No need to linger on TBookmark=pointer. Well, are you sure that the whole FPC+Lazarus codebases properly use freebookmark everywhere? Definitely not. I've never used it in my life. It was the whole point of having TBookmarkStr: not needing to call freebookmark. And we use bookmark a lot in our server app. IMHO FreeBookmark is a relic of the Delphi 12 days. The switch to a managed TBytes only reinforces this hypothesis. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Jonas Maebe schrieb: Graeme Geldenhuys wrote on Wed, 25 Apr 2012: On 25 April 2012 11:08, Ludo Brands ludo.bra...@free.fr wrote: I understand. Just wanted to clarify that, to my knowledge, all 3rd party dataset descendants and some other programs using bookmarks are affected by a change that wanted to minimize compatibility problems. Indeed, and it now has the total opposite effect. Shouldn't such code breaking changes be left to Trunk (2.7.1) and new major FPC releases only. As far as I know, 2.6.x is now a fixes branch which should only allow _bug fix_ commits - nothing more! That's not entirely correct. It's of course mainly for fixes, but small new features or important bug fixes that may break backwards compatibility can also be merged under certain circumstances. What is acceptable and what is not is obviously in the eye of the beholder, and it's not uncommon to also have internal discussions about that among the core developers. From the user VP the newer Delphi versions introduce a couple of breaking changes, so that it's highly desireable to have different Delphi *and* FPC versions available for maintaining legacy projects. In Delphi this ends up in the use of different versions for different projects - but what about FPC (and Lazarus)? What's the last maintained FPC version, compatible with pre-Unicode Delphi? Do we have a compatibility list, between Delphi and FPC/Lazarus versions? IMO changes introduced in Unicode Delphi (2009) should be introduced only into equivalent Unicode FPC, not into older versions. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Marco van de Voort said: If creating the patch is the issue, I'm volunteering ;) You can do it, if not, I will in the coming days. Done, trunk r21037. Affected were tdataset and bufdataset (conversion between Pbufbookmark and tbytes). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
On Wed, Apr 25, 2012 at 1:52 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marco van de Voort said: If creating the patch is the issue, I'm volunteering ;) You can do it, if not, I will in the coming days. Done, trunk r21037. Affected were tdataset and bufdataset (conversion between Pbufbookmark and tbytes). What about 2.6.1, will change in a few days too? Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Marcos Douglas said: Done, trunk r21037. Affected were tdataset and bufdataset (conversion between Pbufbookmark and tbytes). What about 2.6.1, will change in a few days too? When it is sufficiently tested or when I give up waiting. (typically 6-8 weeks). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange Problem!
I am not sure what you mean be your program is not valid. I am
initializing Result. Modify its content and ...
I already observed that if I use either shortstring or use indices to
modify Result, this problem does not occur. But still I can't see what
causes this problem. And I believe it is a bug, isn't it?
Amir
On 04/25/2012 04:25 AM, Flávio Etrusco wrote:
You program isn't valid. You're assigning a constant (a global
variable) to Result, so you shouldn't change it's contents through a
pointer (if you change it normally the compiler+RTL will COW the
value).
You can use a shortstring or:
Result := StringOfChar(' ', 16);
-Flávio
On Tue, Apr 24, 2012 at 7:36 PM, Amira...@aavani.net wrote:
Hi,
I have encountered a strange problem. I developed the following function as
a faster implementation for IntToStr:
function MyIntToStr (n: Int64): AnsiString;
const
MaxLength= 16;
var
CurDigit: PChar;
Sign: Boolean;
begin
Result:= '';
CurDigit:= @(Result [MaxLength]);
Sign:= False;
if n 0 then
begin
Sign:= True;
n:= -n;
end;
if n= 0 then
Exit ('0');
while n 0 do
begin
CurDigit^:= Char (48+ n mod 10);
Dec (CurDigit);
n:= n div 10;
end;
if Sign then
CurDigit^:= '-';
end;
And then, in main , I have
begin
WriteLn (MyIntToStr (5458));
WriteLn (MyIntToStr (5458));
WriteLn (MyIntToStr (2));
end.
The output is:
5458
5458
5452
I tried gdb and noticed the first line of MyIntToStr (Result:= '...') is not
executed correctly. I am using fpc-2.6.0-1.x86_64
Thanks,
Amir
___
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] Strange Problem!
At 01:11 PM 4/25/2012, Amir wrote: I am not sure what you mean be your program is not valid. I am initializing Result. Modify its content and ... I already observed that if I use either shortstring or use indices to modify Result, this problem does not occur. But still I can't see what causes this problem. And I believe it is a bug, isn't it? Yes, a bug in your code. You never set the length of the result string anywhere. Try to initialize the local string with Result:= '' and then call your function with WriteLn (MyIntToStr (1)); WriteLn (MyIntToStr ()); WriteLn (MyIntToStr (333)); WriteLn (MyIntToStr (44)); WriteLn (MyIntToStr (5)); and see what happens... Ralf ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange Problem!
On 25 Apr 2012, at 22:11, Amir wrote: I am not sure what you mean be your program is not valid. This is not valid when Result is an ansistring (or unicodestring), at least if you afterwards start writing to Result via the CurDigits pointer: Result:= ''; CurDigit:= @(Result [MaxLength]); The reason is that ansistring is an implicit pointer type, unlike shortstring. Assigning a constant ansistring to Result means simply that a pointer to that series of spaces is copied into the Result pointer. If you then start modifying Result by hacking behind the compiler's back (which is what you do by using a pointer), the compiler cannot make a copy of that constant string and you start modifying the original constant data that was stored in the program. As a result, when you call the function again, the first assignment will assign whatever you stored in that constant during the previous execution of your function rather than a series of spaces. The solution is to create a local copy of the constant before you start modifying it, which you can do by adding e.g. setlength(Result, length(Result)) after the first assignment. In summary: do not use pointers unless you know in detail how the compiler implements a particular data structure. Using pointers is like using assembler: it can result in fast code, but it's an excellent way to shoot yourself in the foot. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange Problem!
On 25/04/2012 21:11, Amir wrote: I am not sure what you mean be your program is not valid. I am initializing Result. Modify its content and ... I already observed that if I use either shortstring or use indices to modify Result, this problem does not occur. But still I can't see what causes this problem. And I believe it is a bug, isn't it? Try the program at the end. it will print x !!! Strings a pointers. And they do copy on write s2 := s1; means that s1 and s2 point to the same memory (not only the same content, but the same location in mem) Internally the strig knows, that the memory is used by 2 strings s2[1] := 'a'; will trigger copy on write. So s2 gets copied first then modified using pchar does not trigger such copies. so the cod modifies the constant you use for initialization. try UniqueString(Result); program Project1; function Foo: AnsiString; begin Result:= ''; end; var s: String; p: PChar; begin s := Foo; p := @s[1]; p^ := 'x'; writeln(Foo); readln; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange Problem!
On 25 Apr 2012, at 23:53, Amir wrote: The reason is that ansistring is an implicit pointer type, unlike shortstring. Assigning a constant ansistring to Result means simply that a pointer to that series of spaces is copied into the Result pointer. If you then start modifying Result by hacking behind the compiler's back (which is what you do by using a pointer), the compiler cannot make a copy of that constant string and you start modifying the original constant data that was stored in the program. As a result, when you call the function again, the first assignment will assign whatever you stored in that constant during the previous execution of your function rather than a series of spaces. Makes sense! Why does fpc consider the constant string ' ' as an ansistring, not a shortstring? Because your function is declared as returning an ansistring. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote: In our previous episode, Marcos Douglas said: Done, trunk r21037. Affected were tdataset and bufdataset (conversion between Pbufbookmark and tbytes). What about 2.6.1, will change in a few days too? When it is sufficiently tested or when I give up waiting. (typically 6-8 weeks). I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in FPC 2.7.1 only. I invite the FPC 2.6.1 users to write here if they like such breaking changes in fixes_2_6 or not so Marco can make a well-founded decision. At least TDataSet.Bookmark = TBookmark should be reverted to TDataSet.Bookmark = TBookmarkStr immediately so FPC 2.6.1 users don't have to change their code from var bm: tbookmarkstr; [...] bm:= tdataset.bookmark; //do something with tdataset tdataset.bookmark:= bm; //restore DB cursor to var bm: tbookmark; [...] bm:= tdataset.bookmark; try //do something with tdataset tdataset.bookmark:= bm; //restore DB cursor finally tdataset.freebookmark(bm); //avoid memory leak end; for several weeks. Please note, it affects *all* user code with TDataset.Bookmark the problem is not internal to the toolkits only. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
