Not the best thing to do, I know the risks (or I think I do). Also got some alternative ideas in mind... But in case.

I am currently fixing some of the PascalScript issues. When working with strings, it sometimes needs to inc/dec the refcount (or access the length)

Current code does calculate the position of that data as either 1 or 2 times sizeof(Pointer) in front of the actual data. (Not guaranteed for the future, but currently it is there)

Then it accesses the refcount/length using a 32bit type. This raises 2 questions:
- 1 does on a 64bit target the length/ref count ever exceed the 32bit range?
- If not is it endian safe? I would guess not....

Not in svn trunk.

Then it accesses the refcount/length using a 32bit type. This raises 2 questions: - 1 does on a 64bit target the length/ref count ever exceed the 32bit range?

That depends on the program. The RTL definitely can deal with such situations.

I think a standard RTL unit to provide such functionality would be better than all this hacking. I'm not sure whether the best approach would be to reuse the include files from the system unit (so there is no duplicate maintenance), or to create a separate unit with a different interface so that the system unit/compiler interface can continue to evolve independently without breaking the external interface for programs using that unit (but that would require exhaustive tests for every single routine in that unit in order to prevent bit rot).

Jonas

Actually strings are done without hacking. typecasting the pointer, and have fpc deal with it.

Have arrays also changed?

The problem are arrays. Arrays may be of a type, that is not even declared in the running app. Because in pascal script, the script can define its own type. Then the scripts runtime, must be able to finalize it. Well if it is never given to the compiled code, then layout does not matter.

But if a compiled function "Procedure Foo(a: Array of TPoint)" is used from the script, then the type must be declared for the script too. And then script and and exe must be able to deal with this data.

But the script engine currently has no access to a low level finalize/initialize/incref/decref/... for that specific data type.

Yes it be nice to get a real solution for that. But I also need to find a solution that works now.