strange char translation from intel to ppc

[Martin Baxter]

Hi Bernard,

ISOtoMac changes characters you wouldn't expect. There are historic
reasons for this. The answer is to NEVER use the function on blocks of
text containing custom delimiters, but only use it on the user readable
text fragments - i.e. convert each field individually. A pain, yes, but
then you won't have the problem.

Martin Baxter

P.S. I have looked into these functions in detail and would add the
following:

1) They are badly named. They translate between windows-1252 and Mac Roman.

2) They are not the inverse of each other.

3) They are designed to convert the user readable characters, some of
which, historically, were stored in what are properly control character
code positions. Hence the effect you see.

Bernard Devlin wrote:
> I have a stack where I use some non-printable ascii chars as delimiters
> (specifically, ascii 30 and 29).  This stack worked fine on the Windows and
> Linux versions of 3.0 (well, until they crashed or went berserk, but
> everyone's tired of that story).  However, when I moved the stack over to OS
> X (ppc), the application stopped working.  Upon investigation it turned out
> that the delimiters had swapped - they were now ascii 222 and 218.
> 
> Is that to be expected?  Nothing else in the stacks seems amiss, and I'm
> puzzled by this.  I had seen some strange behaviour copying them between
> platforms.  When copied by scp, the stacks were "corrupted", but copied fine
> by ftp binary. When copied by ftp as ascii, opening them crashed Rev 3.0 on
> OS X.
> 
> It's not a big deal, but I suppose it might be a gotcha worth noting for
> anyone else who uses non-printable ascii chars as delimiters.
> 
> Bernard



-- 
I am Not a Number, I am a free NaN