[fpc-pascal] Executing external processes and codepages

[Michael Van Canneyt]

On Wed, 11 May 2016, Jonas Maebe wrote:

>
> Michael Van Canneyt wrote on Wed, 11 May 2016:
>
>> On Wed, 11 May 2016, Jonas Maebe wrote:
>> 
>>> 
>>> Michael Van Canneyt wrote on Wed, 11 May 2016:
>>> 
>>>> On Wed, 11 May 2016, Marco van de Voort wrote:
>>>> 
>>>>> I don't like that. The 3.x idea is to get rid of manual conversions and
>>>>> hack-and-convert-it-as-you-go encoding management, not just rebadge the 
>>>>> old
>>>>> practices to rawbytestring.
>>>> 
>>>> You may not like it, but there is simply no other choice:
>>>> 
>>>> Since you don't know what the receiving program does with the receives
>>>> arguments, all attempts to guess it are erroneous by definition.
>>> 
>>> It will either interpret them according to the code page specified by the 
>>> environment, or not perform any interpretation at all. In both cases, 
>>> converting the arguments to the code page of the environment is the right 
>>> thing to do.
>> 
>> And in the case it makes an assumption of the code page, regardless of
>> environment variables ?
>> 
>> (don't say that doesn't happen. It does, I know a programmer that does so)
>
> The caller can work around such bugs by either
> a) using the pchar version of fpexec, or
> b) specifying the code page that this target program uses in the environment 
> used to invoke it

a) obviously
b) As said, the target program completely ignores the environment.

I was just trying to point out that while your solution is undoubtedly correct
in the large majority of cases (let's assume 99,99%), it is not a rock-hard guarantee.

IMHO, in this large majority of cases, using RawByteString will be correct as well, 
since chances that the calling program uses a different codepage from the 
called one are very small.  (in casu: UTF8)

I am not saying that attempting to convert to the code page used by the
environment is wrong (except maybe in an small minority as pointed out), 
but I do think it is overengineering.

Michael.