(j3.2006) Get_Command_Argument

[Malcolm Cohen]

>> >Which leads back to the largely-ignored original question:
>>
>> Not ignored, you just didn't like the answer!
>
>I said "largely."  And the answer was "it probably works almost
>everywhere for the time being."

No, the answer from me is that we DO NOT want to be doing that.  I even gave 
reasons!

>If c_char isn't default or ASCII or ISO_10646,

IMO C_CHAR certainly is not going to be 10646, it is going to be 8-bit for the 
foreseeable future.

> I don't know how to do
>the translation from default to it.

If you don't know what you want how do you expect us to do it?  At least you 
have a fighting chance of knowing what the C routine you are calling is 
expecting so will have a clue as to whether to encode it as e.g. Shift-JIS or 
UTF-8 or just replace non-ASCII with '?' or raise an error on a non-ASCII char.

>When somebody, in 2032, ports some of my codes that make the assumption
>that c_char == default, which today's processors silently accept, and it
>stops working, coping with that is an expense that could have been
>avoided.

Sometimes one just cannot predict the future.  Having a C_CHAR of GET_COMMAND 
that might do the "wrong translation" for the purposes of whatever the C routine 
you are calling wants would not ameliorate that possibility at all, though it 
might brush it far enough under the carpet so that no-one realised that 
something different was needed until the application failed mid-flight.  This 
would be the opposite of a good thing.

When unpredictable changes occur in the environment, requiring some extra work 
to be done can certainly be the right thing to do.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.