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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
