Re: [fpc-devel] Missing library
On Tue, Jul 5, 2011 at 12:39 PM, Miklos Cserzo wrote: > fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the > missing package? > > "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared > object file: No such file or directory" I have rebuild fpc 2.4.2 for Mandriva some time ago: http://magnifier.sourceforge.net/tmp/fpc-2.4.2-1mandriva.i386.rpm It should work fine in PCLinuxOS and SuSE too You can try to install this package instead of the default one. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Missing library
On Tue, Jul 5, 2011 at 12:39 PM, Miklos Cserzo wrote: > fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the > missing package? > > "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared > object file: No such file or directory" This is a library named differently across distributions. There is no solution here. I don't know what comes with SuSE, but apt-get gets crazy if you force the installation, so if SuSE comes with something other then apt-get it should be safe to just force-install. The standard packages from FPC are built on Fedora I think, so they are fedora-specific because the distributions didn't take enough care to ensure that packages can work properly cross-distribution in all cases. The only solution is making a second RPM set, which might work on SuSE, Mandriva, PCLinuxOS. The dependency to libtinfo.so.5 is added automatically by the RPM build system by inspecting the executable with ldd, that's why it can't be removed. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Missing library
On 05 Jul 2011, at 22:38, Mark Morgan Lloyd wrote: > Miklos Cserzo wrote: >> Hi Folks, >> fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the >> missing package? >> "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared >> object file: No such file or directory" > > Since nobody else has answered: Google suggests that this is part of ncurses, > previous discussion has been inconclusive as to whether this is an FPC or a > SuSE problem. I've never seen it on Debian or Slackware, which suggests the > latter. Actually, the problem is that the libgdb used in the Linux version of the textmode IDE was built on an old SuSE release. It appears that this old SuSE release is one of the only (or last) distributions ever that had a libtinfo.so.5 library. In most (or all) other distributions, its functionality is part of libcurses itself. As a result, afaik the textmode IDE currently only works on very few distros. It would probably be best if it were rebuilt on a different system. See comment 0014986 of http://bugs.freepascal.org/view.php?id=9734 for more info. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Missing library
Miklos Cserzo wrote: Hi Folks, fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the missing package? "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory" Since nobody else has answered: Google suggests that this is part of ncurses, previous discussion has been inconclusive as to whether this is an FPC or a SuSE problem. I've never seen it on Debian or Slackware, which suggests the latter. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 19:28, Alexander Klenin wrote: On Wed, Jul 6, 2011 at 05:12, Martin wrote: TStringList could be made save, and keep the const. Just add additonal references where needed. Agreed with your analysis. This still feels like a wrong design to me -- spreading complexity It's the wrong usage. it shouldn't be used everywhere, then it wouldn't be spread everywhere. the problem was to many people not knowing. It should be used with the same care and low frequency has move or fillbyte is used. like "move(string1, string2, sizeof(pointer))", very dangerous, but in a few places it may have it's place (TSringlist moves the list of strings (the actual pointers, not the char-data) Note that the only reason TString/TStringList does not break too often is that the only way to get access to an element is by calling Get, which increments refcount Not getting this part? Suppose somebody implements "const Result" as I suggested in the link I posted. Then the code like strLst.DelimitedText := strLst[0]; will cause the same problem. Not necessarily strLst.DelimitedText could hold the new value in a temporary/local var (which would add a refcount) to ensure it does not go away. And before strLst.DelimitedText overrides the old strLst[0], it has a refcount from strLst[0] => conclusion, if correctly done, it would still be safe. But again. using const, is like using move or fillbyte on string pointers. The implementer has to know that Alternatively, suppose somebody adds TStringList.ForEach(AVisit: TVisitString) method, then similar problems will be in the visitor procedure procedure VisitString(const AStr: String); Why? As long as the value is in the list, it is referred to by the list? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Wed, Jul 6, 2011 at 05:12, Martin wrote: > TStringList could be made save, and keep the const. Just add additonal > references where needed. Agreed with your analysis. This still feels like a wrong design to me -- spreading complexity all over the place (all the libaries) instead of concenctrating it in a single point (compiler). Still, it seems this is yet another loosing FPC battle for me -- so your suggestion seems the only resort. > >> Note that the only reason TString/TStringList does not break too often is >> that >> the only way to get access to an element is by calling Get, which >> increments refcount > > Not getting this part? Suppose somebody implements "const Result" as I suggested in the link I posted. Then the code like strLst.DelimitedText := strLst[0]; will cause the same problem. Alternatively, suppose somebody adds TStringList.ForEach(AVisit: TVisitString) method, then similar problems will be in the visitor procedure procedure VisitString(const AStr: String); -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 18:56, Alexander Klenin wrote: On Wed, Jul 6, 2011 at 03:44, Jonas Maebe wrote: 2) All such incorrect usage should be removed from LCL and FCL (for example: event handlers in LCL and TStrings methods in FCL). Well, then the situation is hopeless ;-) TStringList could be made save, and keep the const. Just add additonal references where needed. At least with respect to the callback evets (OnChanging, OnChange...) inherited classes have to take care for them self. e.g look at Function TStringList.Add(const S: string): Integer; no events, calls => InsertItem (Result,S); Procedure TStringList.InsertItem(Index: Integer; const S: string); => event: Changing insert the new value => event: Change in the 2 event the string could be lost/ For the 2nd event that is no problem (because it has already been added, and got it's reference via the list) but if it was lost in the first, then corrupted data was added. Yet all that is needed is keep a local copy of the sting to be added, before calling the event Since the const is kept, "Add " still saves exception frame. InsertItem would need an exception frame ( it may be possible to avoid it, but with a lot of trickery only. not sure) Note that the only reason TString/TStringList does not break too often is that the only way to get access to an element is by calling Get, which increments refcount Not getting this part? The local variable in Add/InsertItem may not have a ref count. but once Added, the entry in the list does of ourse have a ref count... This does increase the refcount Flist^[Index].FString:=S; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Wed, Jul 6, 2011 at 03:44, Jonas Maebe wrote: > 2) All such incorrect usage should be removed from LCL and FCL > (for example: event handlers in LCL and TStrings methods in FCL). Well, then the situation is hopeless ;-) Note that the only reason TString/TStringList does not break too often is that the only way to get access to an element is by calling Get, which increments refcount on Result, thus bypassing the bug. If either one day "const Result" will be implemented (as suggested here: http://delphitools.info/2010/07/28/all-hail-the-const-parameters/) or somebody will, with good intentions, implement something like TStrings.ForEach method, the number of breakage modes will substantially increase. > Your suggestions about the "safe" cases were wrong, as far as I can tell. As > soon as a field, global variable or variable from a parent function (in case > of nested functions) is changed, the parameter may also change if it is > declared as const (because the field/(global) variable may contain the value > that was passed in as "const" parameter). Any pointer may also alias them. Ah, of course modifying any non-local string variable should turn optimization off too, I just thought it goes without saying. > Since the behaviour of "const" for automated types is explicitly defined by > Borland as not causing any changes in reference counting (see the note at the > bottom of > http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_Counting ), I > think Martin/Florian's proposal to add the ability for adding extra compiler > checks is best. It's similar to how range and overflow checking are optional. I think the link you provided refers to interfaces, not strings. This is the best I could find on strings, which is much more vague: http://docwiki.embarcadero.com/RADStudio/en/Parameters_(Delphi)#Constant_Parameters -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 18:27, José Mejuto wrote: This changes should be detected ? var a: ansistring; procedure DoSomehting(const v: ansistring); begin a[1]:='a'; end; begin a:='b'; DoSomething(a); end. It would probably best to detect this changes too. But since it would be more of a performance penality, i would like to see it as an option of it's own. (even if only used in debug/development, the penalty could be severe enough to hinter development) Why detect those? Well at current such a trick could actually be used intentionally. and it could work well, if done correctly. But I expect this behaviour is not defined/documented. If the optimizer improves, the optimizer could do thinks that would make any code fail, if it uses such tricks. So better to let people know now, that it isn't safe. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 17:27, Alexander Klenin wrote: Lazarus teams now have many bugs to fix;-) for the LCL we know. Though it isn't sure yet if it is so many. Finding one of them in the LCL, was actually what started the discussion ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Const optimization is a serious bug
Hello FPC, Tuesday, July 5, 2011, 6:44:24 PM, you wrote: JM> Since the behaviour of "const" for automated types is JM> explicitly defined by Borland as not causing any changes in JM> reference counting (see the note at the bottom of JM> http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_Counting JM> ), I think Martin/Florian's proposal to add the ability for adding JM> extra compiler checks is best. It's similar to how range and JM> overflow checking are optional. But adding a checksum over allocated data or only over control data ? This changes should be detected ? var a: ansistring; procedure DoSomehting(const v: ansistring); begin a[1]:='a'; end; begin a:='b'; DoSomething(a); end. Maybe "simply" add a constRefCount field which is only used with the check automagic types turned on ? Anyway the worst behaviour is refcount related do not ? If refcount should be updated and the variable have a constRefCount>0 then something went wrong. Also this mode should not impose a serious performance penalty. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Tue, 5 Jul 2011, Jonas Maebe wrote: On 05 Jul 2011, at 18:27, Alexander Klenin wrote: 2) All such incorrect usage should be removed from LCL and FCL (for example: event handlers in LCL and TStrings methods in FCL). Changing TStrings like that would break the compilation of any code that overrides its methods (since they also have to repeat/leave out const). Personally, I think this solution is inferior to my proposal of implementing the optimization correctly by default. Your suggestions about the "safe" cases were wrong, as far as I can tell. As soon as a field, global variable or variable from a parent function (in case of nested functions) is changed, the parameter may also change if it is declared as const (because the field/(global) variable may contain the value that was passed in as "const" parameter). Any pointer may also alias them. Since the behaviour of "const" for automated types is explicitly defined by Borland as not causing any changes in reference counting (see the note at the bottom of http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_Counting ), I think Martin/Florian's proposal to add the ability for adding extra compiler checks is best. It's similar to how range and overflow checking are optional. I agree with this proposal. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05 Jul 2011, at 18:27, Alexander Klenin wrote: > 2) All such incorrect usage should be removed from LCL and FCL > (for example: event handlers in LCL and TStrings methods in FCL). Changing TStrings like that would break the compilation of any code that overrides its methods (since they also have to repeat/leave out const). > Personally, I think this solution is inferior to my proposal of > implementing the optimization > correctly by default. Your suggestions about the "safe" cases were wrong, as far as I can tell. As soon as a field, global variable or variable from a parent function (in case of nested functions) is changed, the parameter may also change if it is declared as const (because the field/(global) variable may contain the value that was passed in as "const" parameter). Any pointer may also alias them. Since the behaviour of "const" for automated types is explicitly defined by Borland as not causing any changes in reference counting (see the note at the bottom of http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_Counting ), I think Martin/Florian's proposal to add the ability for adding extra compiler checks is best. It's similar to how range and overflow checking are optional. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Wed, Jul 6, 2011 at 02:41, Martin wrote: > On 05/07/2011 16:28, Florian Klaempfl wrote: >> >> As written in some of the bug reports, I consider as a better solution: >> - Pointer checking of constant parameters of types like ansistrings, >> interfaces at procedure exit. Together with heaptrc and keep_released >> enabled, this catches all cases of disposed const parameters and >> probably a lot more pointer errors. >> - Like the scrambling of local parameters with -gttt, some checksumming >> for contant parameters could be implemented. This catches not only the >> modified constant parameter but also aliasing problems. > > There would be the possibility to extend heaptrc mem manager. > Every mem block gets a "release-lock"- or const-counter (and maybe a > checksum field). > > then any memory used in a const param, can be protected (via the mem > manager) against release (ONLY if compiled with sanity check). > > That would catch the releases due to refcount going to 0, were it must not > be allowed. > > The checksum can be used for general checking. > > The checksum should be toggle-able by a 2nd switch (and maybe with a > configurable upper limit for mem size, so to skip tests for very large data) > This seems complicated to me. How about a simple memory poisoning? For example, with the attached patch the code trying to access const string parameter which has been already destroyed is likely to fail spectacularly instead of "maybe working" depending on memory layout. -- Alexander S. Klenin heaptrc_poisoning.patch Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
cobines schrieb: procedure mclass.dot(const s: string); Here you know that you cannot modify 's'. But you may not know that you cannot also change mclass.ftext variable, which actually 's' points to because apparently someone called mclass.dot(mclass.fsometext). You *can* change mclass.ftext, but this can cause *trouble*. Maybe it is programmer error and it should be said: "never call mclass.dot with mclass.ftext as a parameter because it may crash". Maybe the const should have never been there in the first place. I would say if procedure writes to some non-local strings, never add 'const' to parameter. Good advice :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Tue, Jul 5, 2011 at 22:51, Martin wrote:
> I think you misunderstood me. There is a (or there may be) a bug. But
> *not* in the compiler, and *not* in the implementation of "const string".
> I explicitly pointet that out on the top of the quotation "I don't think it
> is a bug." (with reference to the feature itself)
>
> The bug(s) is/are in user code, where the const construct is *incorrectly*
> used.
Well, then the following changes are in order:
1) The documentation should recommend users to never use "const
string" parameters
except cases where they can prove it to be safe.
Moreover, since the safety of such code may be compromised by
completely unrelated changes
(e.g. by adding {$INLINE OFF} for debugging purposes),
"const" modifier should not be used at all except the most
performance-critical code.
This is quite the opposite of the current practice, where all string
parameters are usually
marked by "const".
2) All such incorrect usage should be removed from LCL and FCL
(for example: event handlers in LCL and TStrings methods in FCL).
Personally, I think this solution is inferior to my proposal of
implementing the optimization
correctly by default.
> An I was merely pointing out, that any usage without knowledge what it does
> is incorrect usage (even if by accident it works). Therefore one might
> consider such unaware/unknowing usage as a bug (a bug in the users code)
Ok, FPC and Lazarus teams now have many bugs to fix ;-)
I''ll start reviewing my TAChart code in a few days.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 16:28, Florian Klaempfl wrote: As written in some of the bug reports, I consider as a better solution: - Pointer checking of constant parameters of types like ansistrings, interfaces at procedure exit. Together with heaptrc and keep_released enabled, this catches all cases of disposed const parameters and probably a lot more pointer errors. - Like the scrambling of local parameters with -gttt, some checksumming for contant parameters could be implemented. This catches not only the modified constant parameter but also aliasing problems. There would be the possibility to extend heaptrc mem manager. Every mem block gets a "release-lock"- or const-counter (and maybe a checksum field). then any memory used in a const param, can be protected (via the mem manager) against release (ONLY if compiled with sanity check). That would catch the releases due to refcount going to 0, were it must not be allowed. The checksum can be used for general checking. The checksum should be toggle-able by a 2nd switch (and maybe with a configurable upper limit for mem size, so to skip tests for very large data) Variables on the stack, do not get the mem-alloc protection => but they can not be released early anyway ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Am 04.07.2011 22:39, schrieb Chad Berchek: > I've been reading over some of the recent discussion about reference > counting problems with const string parameters. I've done some > experiments and I believe that the so-called const optimization is a > serious flaw, not just a corner case of questionable legitimacy. I have > some sample code I will show which should be quite scary. Additionally, > this is a security vulnerability. It is also a quiet bug, because it may > go undetected for a long time but randomly result in unreproducible > crashes. > > Consider: > * It does not affect just global variables but also object fields. While > global variables are used rarely, object fields are used constantly in OOP. > * It does not affect just strings but also interfaces and dynamic arrays. It affects more types, even shortstring suffers from it, the program does not crash but might behave not as expected (similiar examples can be created for normal arrays or records as well): var s : shortstring; procedure p(const s1 : shortstring); begin s:='Ops'; writeln(s1); end; begin s:='Hello world'; p(s); end. I see it only as a either or all or none: either the const optimization is done for no types or for all types where it's useful. Everything else is even more dangerous (if you consider this behaviour as dangerous) because the outcome is unpredictible. However, I doubt that people will be happy, if huge data arrays, records or shortstrings are always copied and no const optimization is carried out. As written in some of the bug reports, I consider as a better solution: - Pointer checking of constant parameters of types like ansistrings, interfaces at procedure exit. Together with heaptrc and keep_released enabled, this catches all cases of disposed const parameters and probably a lot more pointer errors. - Like the scrambling of local parameters with -gttt, some checksumming for contant parameters could be implemented. This catches not only the modified constant parameter but also aliasing problems. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
2011/7/5 : > You can always fool the compiler. The compiler trusts you and assumes that > what you tell her is true, namely, that the called code will not modify the > const parameter (in the case of an ansistring: a pointer). That's it. Based > on this she may or may not perform some optimizations. In case of ansistrings, inside the procedure you cannot also finalize the instance that the const parameter points to. But you can modify that instance through other variables. For example : procedure mclass.dot(const s: string); Here you know that you cannot modify 's'. But you may not know that you cannot also change mclass.ftext variable, which actually 's' points to because apparently someone called mclass.dot(mclass.fsometext). Maybe it is programmer error and it should be said: "never call mclass.dot with mclass.ftext as a parameter because it may crash". Maybe the const should have never been there in the first place. I would say if procedure writes to some non-local strings, never add 'const' to parameter. It is easy to start adding 'const' to every parameter but some may not be aware of the dangers it may later bring. It should be a well thought decision. -- cobines ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Thaddy schrieb: That is also part of the speed optimization: the compiler doesn't have to check because of this contract. More important: the compiler can omit try-finally sections, otherwise required for safe refcounting of non-const strings. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Tue, Jul 5, 2011 at 1:04 PM, Thaddy wrote: > On 5-7-2011 12:34, Felipe Monteiro de Carvalho wrote: >> >> Maybe the compiler should start issuing hints or warnings for all >> places where one uses const with ansistring, so that people who don't >> care about the speed advantage can start removing those const >> ansistrings from their code base. >> > Yes, but is is no bug! ppcontroller.pas(40,31) Hint: Parameter "AStartDate" not used That's also not a bug, but nevertheless the compiler issued a Hint for it. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 11:24, michael.vancann...@wisa.be wrote: On Tue, 5 Jul 2011, Martin wrote: On 05/07/2011 04:02, Chad Berchek wrote: Martin wrote: I don't think it is a bug. ... "(const s: string)" is a declaration by the programmer, that the variable (the string) will not be modified at all. That is neither by the procedure called, nor by any code outside the procedure, via any other reference to the data. If the programmer sticks to what he declared, then it works, if not it crashes. Is that true? I am not necessarily asserting that your statement is false; it could well be true. However I personally have not seen it documented so if anyone has a reference I would like to see it. As far as I have been able to tell from the docs of Delphi and FPC, the const declaration does NOT mean the programmer promises to not modify the instance; it means he promises to not modify the variable, which the compiler does indeed enforce. Well, I have pointed out myself,in my mail, that it probably needs more documentation. I do not know if it is documented or not. But it is the answer, I have gotten several times from developers in the FPC team. So for all I know it is the intended behaviour. At least intended in FPC (and apparently either intended or at least implemented in Delphi). So if there is no documentation for it, then it would appear a problem of documentation, rather than a bug in the compiler (Again all based on the statements I was given) There is no bug. I think you misunderstood me. There is a (or there may be) a bug. But *not* in the compiler, and *not* in the implementation of "const string". I explicitly pointet that out on the top of the quotation "I don't think it is a bug." (with reference to the feature itself) The bug(s) is/are in user code, where the const construct is *incorrectly* used. An I was merely pointing out, that any usage without knowledge what it does is incorrect usage (even if by accident it works). Therefore one might consider such unaware/unknowing usage as a bug (a bug in the users code) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
michael.vancann...@wisa.be schrieb: On Tue, 5 Jul 2011, Martin wrote: On 05/07/2011 04:02, Chad Berchek wrote: Martin wrote: I don't think it is a bug. ... "(const s: string)" is a declaration by the programmer, that the variable (the string) will not be modified at all. That is neither by the procedure called, nor by any code outside the procedure, via any other reference to the data. If the programmer sticks to what he declared, then it works, if not it crashes. Is that true? I am not necessarily asserting that your statement is false; it could well be true. However I personally have not seen it documented so if anyone has a reference I would like to see it. As far as I have been able to tell from the docs of Delphi and FPC, the const declaration does NOT mean the programmer promises to not modify the instance; it means he promises to not modify the variable, which the compiler does indeed enforce. Well, I have pointed out myself,in my mail, that it probably needs more documentation. I do not know if it is documented or not. But it is the answer, I have gotten several times from developers in the FPC team. So for all I know it is the intended behaviour. At least intended in FPC (and apparently either intended or at least implemented in Delphi). So if there is no documentation for it, then it would appear a problem of documentation, rather than a bug in the compiler (Again all based on the statements I was given) There is no bug. You can always fool the compiler. The compiler trusts you and assumes that what you tell her is true, namely, that the called code will not modify the const parameter (in the case of an ansistring: a pointer). That's it. Based on this she may or may not perform some optimizations. That's my opinion as well :-) All the rumor about hard to find errors IMO is due to the users, which simply should avoid "const" when their overall code then may break itself. I'd second that "const" with object references is a bug, and should be removed from all library code (RTL, FCL, LCL...). But this is only a matter of style, not affecting compilation in any way. [examples snipped] Will not produce the desired effect. The compiler cannot warn you against this. I understand that with Ansistrings it's slightly more convoluted than this, but it's the same principle. People with according bugs in their code should be happy with an added compiler option, that disables "const" parameter optimization. That's a quick workaround for urgent fixes, where otherwise an in-depth analysis of the entire application were required. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 5-7-2011 12:34, Felipe Monteiro de Carvalho wrote: Maybe the compiler should start issuing hints or warnings for all places where one uses const with ansistring, so that people who don't care about the speed advantage can start removing those const ansistrings from their code base. Yes, but is is no bug! It is a contract between the compiler and the programmer in which it is expected that the string will not be modified inside a procedure, function or method. That is also part of the speed optimization: the compiler doesn't have to check because of this contract. This is also the case in many other languages. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Missing library
Hi Folks, fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the missing package? "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory" Cheers, miklos ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Maybe the compiler should start issuing hints or warnings for all places where one uses const with ansistring, so that people who don't care about the speed advantage can start removing those const ansistrings from their code base. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On Tue, 5 Jul 2011, Martin wrote: On 05/07/2011 04:02, Chad Berchek wrote: Martin wrote: I don't think it is a bug. ... "(const s: string)" is a declaration by the programmer, that the variable (the string) will not be modified at all. That is neither by the procedure called, nor by any code outside the procedure, via any other reference to the data. If the programmer sticks to what he declared, then it works, if not it crashes. Is that true? I am not necessarily asserting that your statement is false; it could well be true. However I personally have not seen it documented so if anyone has a reference I would like to see it. As far as I have been able to tell from the docs of Delphi and FPC, the const declaration does NOT mean the programmer promises to not modify the instance; it means he promises to not modify the variable, which the compiler does indeed enforce. Well, I have pointed out myself,in my mail, that it probably needs more documentation. I do not know if it is documented or not. But it is the answer, I have gotten several times from developers in the FPC team. So for all I know it is the intended behaviour. At least intended in FPC (and apparently either intended or at least implemented in Delphi). So if there is no documentation for it, then it would appear a problem of documentation, rather than a bug in the compiler (Again all based on the statements I was given) There is no bug. You can always fool the compiler. The compiler trusts you and assumes that what you tell her is true, namely, that the called code will not modify the const parameter (in the case of an ansistring: a pointer). That's it. Based on this she may or may not perform some optimizations. For what it's worth, you can recreate the alleged problem just as easily in C or with non-reference-counted classes. For example: uses sysutils,classes; Var C : TComponent; Procedure DoSomething(Const AC : TComponent); begin FreeAndNil(C); AC.Name:=AC.Name+'_component'; // You can skip this, even. Writeln(AC.Name); end; begin C:=TComponent.Create(nil); C.Name:='Something'; DoSOmething(C); end. Will not produce the desired effect. The compiler cannot warn you against this. I understand that with Ansistrings it's slightly more convoluted than this, but it's the same principle. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
On 05/07/2011 04:02, Chad Berchek wrote: Martin wrote: I don't think it is a bug. ... "(const s: string)" is a declaration by the programmer, that the variable (the string) will not be modified at all. That is neither by the procedure called, nor by any code outside the procedure, via any other reference to the data. If the programmer sticks to what he declared, then it works, if not it crashes. Is that true? I am not necessarily asserting that your statement is false; it could well be true. However I personally have not seen it documented so if anyone has a reference I would like to see it. As far as I have been able to tell from the docs of Delphi and FPC, the const declaration does NOT mean the programmer promises to not modify the instance; it means he promises to not modify the variable, which the compiler does indeed enforce. Well, I have pointed out myself,in my mail, that it probably needs more documentation. I do not know if it is documented or not. But it is the answer, I have gotten several times from developers in the FPC team. So for all I know it is the intended behaviour. At least intended in FPC (and apparently either intended or at least implemented in Delphi). So if there is no documentation for it, then it would appear a problem of documentation, rather than a bug in the compiler (Again all based on the statements I was given) Anyway, if you do not like the feature do not use it. Unfortunately, that is not true. I don't have to use const in my own code, but I cannot control the fact that it is already widely used in other libraries, including those of FPC. Well yes. But that is not a problem limited to the "const string param". Any code you use in your app, can contain any kind of bug. I just want to ask, after looking at the demo, is this not the least bit scary to anyone? I mean, you can make one very simple, tiny change and turn a perfectly working program into an immediate crash for no apparent reason. The secrets are buried in there. In a real world scenario you wouldn't be able to see it crash so easily. It may or may not crash, or it may just crash much later, or it may not crash but just be a security vulnerability waiting for someone to discover. Very true, in fact the whole issue has only recently been discovered in the LCL too (as a bug in the LCL) We also have to remember that *probably almost nobody* remembers fixing a bug related to this. That's because most people who come up against this bug probably have no clue what is happening and only by making some other changes do they coincidentally "fix" it. I propose that for a problem like this you cannot rely on reported incidents to determine how frequent it is. I would gop as far as to say, every time someone use a "const string param" without knowing the real meaning, the resulting code should be considder buggy. Even if it works by accident. Wrongly written code, that works by accident, to me is close enough to being a bug. Looking at it like this, it is probably correct to say, that this "feature" has cause a lot of bugs already. But it doesn't mean the feature itself is buggy. It maybe that it isn't documented well enough, as to few people are aware of it. It may even be that the indrotuction of this feature was not a good idea, or should at least have been done in a way that would make the "risks" more obvious. Of course "should have done" is past, little point in discussing that now. BTW, there are similar pitfalls with functions like fillchar, or move x: array of string; fillbyte(x[0], (length(x)-1)*sizeof(string), 0) If there are any strings with content in the array, it will leak using "move()" on an array like this will lead to crashes later in the code... Only difference, for those functions more (not all) people know of the dangers... This is one of the reasons, why I have asked for a range-ceck like feature for such const params (http://bugs.freepascal.org/view.php?id=19605) - Not only would it help finding where the problem occurs - It would also help creating awareness: Many people tend to switch on all the check options (range, overflow, io, stack...) during development. So would they do for a check detecting "const param" issues. The hope is that simple by noting the features, some would look up it's documentations. The others would do so, once the check raises an alert. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] Runtime error 217
> Am 04.07.2011 17:42, schrieb Ludo Brands: > > Just spent an hour debugging a runtime error 217. No > information just > > runtime error 217, compilation aborted under lazarus and with > > lazbuild. Rebuild fpc with debug information and ran the > "offending" > > compile command from the command line (on solaris). FPC > crashed with > > an unhandled exception "disk full error" in TCFileStream.Read??? > > Where does it do so? Unfortunately I haven't saved the backtrace and the volume has been restored from backup. So, truss output gone and I can't reproduce the problem. However, from memory TCFileStream.Read tppufile.reloadbuf tppufile.readdata tppumodule.load_interface tppumodule.loadppu tppumodule.load_usedunits No guarantee ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
