[fpc-pascal] Executing external processes and codepages

Jonas Maebe jonas.maebe at elis.ugent.be
Wed May 11 11:45:43 CEST 2016


Michael Van Canneyt wrote on Wed, 11 May 2016:

> On Wed, 11 May 2016, Marco van de Voort wrote:
>
>> In our previous episode, Jonas Maebe said:
>>
>>> The filesystem encoding is fine to find the binary on Unix, but the
>>> parameters you specify to that binary will be interpreted by that same
>>> binary once it's running. It will not interpret those parameters
>>> according to the filesystem encoding, but according to whatever is
>>> determined to be the DefaultSystemCodePage *by that executed binary*.
>>
>> I do understand that, and it will be fine most of the time.
>>
>> I'm not sure what you are suggesting as alternative. Saving the encoding at
>> startup, so it can be reused in cases like this, in case somebody change
>> defaultsystemcodepage?

We have to look up the code page to use in the current program's  
environment at the time fpexec*() is called (or, in case the  
environment is specified explicitly, in that environment)

> Why not simply make the exec calls use RawByteString ?

They will use RawByteString in any case, because we don't want the  
caller's string arguments to be converted before the routine is  
called, for two reasons:
1) a plain "ansistring" argument could result in data loss
2) we will have to convert the data afterwards to the correct code  
page anyway, so adding a potential extra conversion by declaring the  
argument as e.g. utf8string would serve no purpose (in the worst case  
it would introduce an additional, useless, conversion; in the best  
case it would move the conversion from the callee to the caller side)

> It is then the responsability of the programmer.

It is the responsibility of the programmer when they call the pchar  
version of those routines. The string versions of all other fp*()  
routines also convert the arguments to the appropriate code page  
required by their purpose.

> We should not fall in the trap of overengineering.

We should not fall in the trap of going for an inconsistent,  
buggy-by-design solution because doing it correctly is not trivial.


Jonas



More information about the fpc-pascal mailing list