On Tue, Jul 5, 2011 at 14:02, Chad Berchek ad...@vobarian.com wrote:
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
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 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
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
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
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
___
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
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
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
On Tue, Jul 5, 2011 at 1:04 PM, Thaddy tha...@thaddy.com 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
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
2011/7/5 michael.vancann...@wisa.be:
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
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
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
On Tue, Jul 5, 2011 at 22:51, Martin f...@mfriebe.de 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
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
On Wed, Jul 6, 2011 at 02:41, Martin f...@mfriebe.de 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
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
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
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
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
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
On Wed, Jul 6, 2011 at 03:44, Jonas Maebe jonas.ma...@elis.ugent.be 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
On 05/07/2011 18:56, Alexander Klenin wrote:
On Wed, Jul 6, 2011 at 03:44, Jonas Maebejonas.ma...@elis.ugent.be 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 ;-)
On Wed, Jul 6, 2011 at 05:12, Martin f...@mfriebe.de 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
On 05/07/2011 19:28, Alexander Klenin wrote:
On Wed, Jul 6, 2011 at 05:12, Martinf...@mfriebe.de 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
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
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
On Tue, Jul 5, 2011 at 12:39 PM, Miklos Cserzo
miklos.cse...@eok.sote.hu 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
29 matches
Mail list logo
