Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-05

an idea about "const param: string"

4 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin

I know there are lots of ideas, and many ideas without the person from whom it originates being able or willing to work on it. This is one of them. So if it will simply vanish, never mind. Anyway maybe I am lucky, and with this idea I plant a seed, and someday....

I recently run across the following situation (again)

procedure Foo(const s: string;)
begin
   // do something
   CallBar();
   // do more
end;
var GlobalText: String
Foo(GlobalText);

and then in CallBar, "GlobalText" is modified. Which is not allowed. http://lists.freepascal.org/lists/fpc-devel/2010-July/020966.html http://lists.freepascal.org/lists/fpc-devel/2010-July/020974.html

The problem of course is that such code is incredible hard to find.

I was thinking it would be cool to have something like range-checks, but for those strings.

Ideally, the string would be flagged, and other code trying to access it would check this. But that would mean that all units, packages everything would need awareness, and had to be compiled with support for the flag.... Not really practical.

However at least some test would probably work.
If compiled with -Cc (Check Constant string param) or whatever compiler option it would be, then the code in Foo could have checks.

If foo would copy the value of s (only the address: @s[0], not the string) and increase the ref-count of s (it still is a pointer to the original s), then Foo could check on exit. If anyone modified s, then copy-on-write would have kicked in. either the address in s, or the ref count would have changed.

That would allow to give at least a warning that something wrong was done.

Martin

Reply by email

Alexander Klenin
to Martin
Martin wrote 20 lines
I was thinking it would be cool to have something like range-checks, but for those strings. Ideally, the string would be flagged, and other code trying to access it would check this. But that would mean that all units, packages everything would need awareness, and had to be compiled with support for the flag.... Not really practical. However at least some test would probably work. If compiled with -Cc (Check Constant string param) or whatever compiler option it would be, then the code in Foo could have checks. If foo would copy the value of s (only the address: @s[0], not the string) and increase the ref-count of s (it still is a pointer to the original s), then Foo could check on exit. If anyone modified s, then copy-on-write would have kicked in. either the address in s, or the ref count would have changed. That would allow to give at least a warning that something wrong was done.

Perhaps an easier thing to do is to make const string param optimization controllable by compiler switch and/or directive.
This way, users who prefer safe behavior, can get it, and those who are willing to take a risk still get a (weaker) tool to detect the error --
by checking if the program works with the switch but crashes without it.

Alexander S. Klenin

Reply by email

Martin
to Alexander Klenin
Alexander Klenin wrote 7 lines
Perhaps an easier thing to do is to make const string param optimization controllable by compiler switch and/or directive. This way, users who prefer safe behavior, can get it, and those who are willing to take a risk still get a (weaker) tool to detect the error -- by checking if the program works with the switch but crashes without it.

The only thing that the const param (afaik) does to a string is the optimization to skip the ref count (and with that the implicit try finallyt block, that the compiler generates).

Otherwise strings are already pointer, so no need to make them pointer to pointer using "const" (not even sure if it will double pointer it, probably not).
So users who do not want this, just leave the "const" away.

Also checking for crashes is not that simple. It doesn't always lead to a crash. Or not immediately, so you get a 100 runs that are fine, you publish the app, and crashes will happen.

If for some reason you wish to use "const" optimization on strings, then it would be good to have a tool to check it's safety. Of course, as with range-checks, and others too, it doesn't always happen, the check is just another chance to find an issue, not a guarantee...

Yet, there was that link to "who to shoot yourself in the foot with different programming languages" => the pascal compiler does not let you shoot yourself in the foot.
Well it does, it gives you "const s: string" params....

Martin

Reply by email

Alexander Klenin
to Martin
Martin wrote 13 lines
On 28/05/2011 22:47, Alexander Klenin wrote: > > Perhaps an easier thing to do is to make const string param optimization > controllable by compiler switch and/or directive. > This way, users who prefer safe behavior, can get it, > and those who are willing to take a risk still get a (weaker) tool to > detect the error -- > by checking if the program works with the switch but crashes without it. > The only thing that the const param (afaik) does to a string is the optimization to skip the ref count (and with that the implicit try finallyt block, that the compiler generates).

Yes, and the only thing I propose is to let the programmer turn this skipping off.

Yet, there was that link to "who to shoot yourself in the foot with different programming languages" => the pascal compiler does not let you shoot yourself in the foot. Well it does, it gives you "const s: string" params....

I agree.

Alexander S. Klenin

Reply by email