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

Reply via email to